[Zope-Coders] test failures in DateTime

Tim Peters tim@zope.com
Fri, 28 Sep 2001 14:32:50 -0400


[Tim]
> How many bytes do each of the alternatives consume?  In my
> experience, most buggy date/time gimmicks are driven by an
> overwhelming need to conserve space.

[Tres Seaver]
> ROFL.  DateTime.DateTime instances are optimized *entirely* in the other
> direction, to trade space off in favor of rendering speed.

I will punish my experience accordingly <wink>.

> ...
> The bugs in question are truly actually bugs in the test's handling
> of floating point rounding, exposed by the changes in rounding between
> Python 1.5.2 and Python 2.1.

?  I'm not aware of any rounding differences, unless you mean the change in
float->string via repr(float) (from 12 significant digits in 1.5.2 to 17 in
1.6; str(float) is still 12 even in 2.2).  Is that what you mean?

> We should fix the tests, and then carefully consider Stephan and
> Andreas' proposal:  one thing to examine is the relative space/time
> tradeoffs between mxDateTime and the current implementation:  the
> obsession with rendering speed evident in the current design was
> based on lots of blood spilt a fair while ago; we ignore that at
> our peril.

OK.

> BTW, DateTime.DateTime instances are (effectively)immutable, so lots
> of the nastiness involved in swapping out alternate implementations
> should be smoothed away -- any implementation of the (fat) query
> interface, which will also support the current construction
> semantics, would do.

Note that 2.2 supports computed attributes (called properties) without
invoking the general getattr machinery:

>>> class C(object):
...     def __init__(self, s):
...         self.s = s
...     def __getx(self):
...         return self.s + "."
...     x = property(__getx, doc="self's value with a period")
...
>>> print C('abc').x
abc.
>>>

Per-attribute setters and deleters can also be specified.

> While we are at it, we should look into aliasing the special rich
> comparison operators onto the existing DateTime.DateTime methods:
>
>   greaterThan(self,t)
>   greaterThanEqualTo(self,t)
>   equalTo(self,t)
>   notEqualTo(self,t)
>   lessThan(self,t)
>   lessThanEqualTo(self,t)
>
> The performance of DT instance comparison in Python 2 would be
> enhanced a lot.

Cool!