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 ZDB.
-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 ZDB to 'fix' pickles, because
you just know you're going to corrupt someone's ZDB, and that's just
noone's idea of fun.

There are sensible ways of upgrading the ZDB. 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 zope (AT) zope (DOT) org but for
zope-dev (AT) zope (DOT) org. From the beginning, actually. I suggest we move all
further discussion there.

Philipp

Zope maillist - Zope (AT) zope (DOT) org

** No cross posts or HTML encoding! **
(Related lists -

)

Chris Withers wrote:
Philipp von Weitershausen wrote:

>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.

I don't see any need for diabolical creations ;-) Just the deprecation
warnings will suffice.
(which will promptly be added to warn filters, and only fixed when
DateTime really goes away *sigh*)

, so take this example:

A piece of code calls bobobase_modification_time() which currently
returns a DateTime; after that the piece of code calls some
DateTime-specific methods on the returned object. Now in Zope 2.12 we
make bobobase_modification_time() return a datetime.datetime and
subsequently the piece of code would fail. There are a lot of pieces of
code like this in third party products

We could deprecate DateTime now to warn people about that. But then
their product would only either work with Zope <2.12 or with Zope >2.12
(depending on whether it still expects the DateTime API or the
datetime.datetime API); it would not with both versions. That's a harsh
upgrade plan and it would probably take ages before people would adopt
Zope 2.12.

With a frankendatetime in Zope 2.10, however, they could still call
DateTime-specific methods on the return value of
bobobase_modification_time(). They'd get deprecation warnings telling
them to use the datetime.datetime API instead. That would work
instantly, not only in Zope 2.12. That way they could smoothly upgrade
their products.

By the way, I've come to think that touching the current DateTime
implementation wouldn't be a good idea, mostly because of the old
pickles issue. The frankendatetime should be a separate class that
subclasses datetime.datetime, provides old-style DateTime compatability
and has datetime.datetime-compatible pickles.

Philipp

Zope maillist - Zope (AT) zope (DOT) org

** No cross posts or HTML encoding! **
(Related lists -

)

Lennart Regebro wrote:
I agree, official deprecation and warnings should only happen when we
have a real backwards compatibility and transition-path. Which would
include what you call a "frankendatetime". :-)

Which, as I understand it, is what J Herrman wanted to create

Not if I understand
correctly.
There he says something about using datetime as a storage, but not as
the end point of a deprecation period.

Philipp

Zope maillist - Zope (AT) zope (DOT) org

** No cross posts or HTML encoding! **
(Related lists -

)