-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andreas Jung wrote: > > --On 25. August 2007 12:33:41 -0400 Tres Seaver <[EMAIL PROTECTED]> > wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Andreas Jung wrote: >>> Hi, >>> >>> perhaps the sun burned too long on my brain today but I investigated >>> some options for replacing DateTime with Python's datetime module. Zope >>> 3 uses datetime and we all know that the DateTime implementation sucks. >>> Especially the timezone implementation has a bunch of problems (count >>> the bugtracker issues related to timezone errors). >>> >>> Constraints: >>> We can not get rid of the DateTime class and its API for backward >>> compatibility reasons. >>> >>> Idea: >>> The DateTime class remains in place and uses an instance attribute to >>> represent the original value of a DateTime object as instance of >>> datetime. Calls to the old DateTime API are proxied to corresponding >>> calls of the datetime API (or emulated) >>> >>> Efforts so far: >>> I have some quick-and-dirty implementation that can construct the >>> datetime instance directly within the DateTime constructor and when >>> loading an object from the ZODB (using a custom __setstate__() >>> implementation...could be used for an on-the-fly migration). This seems >>> to work properly. For timezone related issues I am using pytz. However >>> there is a problem with using pytz: the timezone names supported by >>> pytz are sometimes different from the standard one. E.g. 'GMT+0400' is >>> represented in pytz as '/Etc/GMT+0400'...however that seems to be >>> solvable. >>> >>> Before digging deeper I would like to hear some opinions if this seems a >>> reasonable approach? Unlikely that we can achieve 100% backward >>> compatibility but possibly 99%....thoughts...comments? >> I'm generally in favor of this, but only if we eggify the *current* >> DateTime implementation such that people who rely on the incompatible >> behavior can specify the older version. > > Jup, but eggification would likely be the last (and possibly the most easy) > step :-)
Eggifying the current package shouldn't be hard (it has no dependencies except for zope.interface. In fact, it looks as though Philipp has done it already: http://mail.zope.org/pipermail/checkins/2007-June/010134.html So releasing an egg from there should be straightforward. >> Note that a lot of the code in DateTime is the constructor DWIM, which >> datetime completely lacks (in fact, the lack of a string-to-datetime >> parser in the standard library is a major pain). That DWIM *must* >> remain in place, even in the new version, as too much application code >> depends on it. > > DWIM? The conversion to datetime happens in my place after calling > _parse_args() which is a big pita code...if you mean this...yes, I would > _never_ touch it. The parsing is what I meant, along with the DWIM related to number of arguments passed to the constructor. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG0I9P+gerLs4ltQ4RAjIoAJ42UYkVxnqmjQxIVavDbE33URBoqACfad00 7hoDj7oxRy+KyhdrlxqidIA= =QvY6 -----END PGP SIGNATURE----- _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )