Andrew Milton wrote: > +-------[ Philipp von Weitershausen ]---------------------- > > | 2. If we find it's possible, we rid the current DateTime implementation > | and recreate the DateTime class by subclassing datetime.datetime. For > | backwards compatability, we make sure that old pickles can be revived > | and that the old DateTime API is supported for two more Zope releases. > | > | 3. After two releases we get rid of the old DateTime API and will > | provide a script to migrate old DateTime pickles to datetime.datetime > | pickles in the ZODB. > > -1 for any scheme that deliberately breaks currently working code / installs.
Agreed. Deprecation is a way of deliberately killing you softly :). Seriously, there's no going forward without getting rid of stuff. Deprecation is a good way of dealing with getting rid of stuff without having currently working code broken instantly. > -1 for any scheme that involves diddling the ZODB to 'fix' pickles, because > you just know you're going to corrupt someone's ZODB, and that's just > noone's idea of fun. There are sensible ways of upgrading the ZODB. Zope 3 has had it since 3.0 (called generations) and they've been working reasonably well for these things. > Didn't see any mention of fixing ZClasses (not sure if that's an issue). I'm not sure it is either, but this would be something to be discussed in the proposal discussion process, I guess. But now that you've mentioned it, I will investigate and possibly include notions in the proposal. > I'm the first in line of the people wanting Zope DateTime to die. However, you > need to leave it there. Fix Zope to internally use something different, and > provide a new implementation that 'sensible' people can use going forwards. I don't think that'll work. I've thought about just letting DateTime die and switch to datetime.datetime over completely. However, code that expects Zope to return DateTime-compatible objects would break. I think we need Zope to use some frankendatetime (a datetime.datetime that also supports the old DateTime API) throughout the deprecation period. Whenever people make a call to the old DateTime API on a frankendatetime object, they'll get a deprecation warning telling them to use the datetime.datetime API instead. After the deprecation phase is over, Zope 2 can return pure datetime.datetime objects. By the way, this is really not a thread for firstname.lastname@example.org but for [EMAIL PROTECTED] From the beginning, actually. I suggest we move all further discussion there. Philipp _______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )