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...
Good point, I don't see a nice way around this though :-S Your frankendatetime is one possibility, but for me it feels just as nasty as the scenario you describe above :-S
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.
Yup...
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.
OK, I'm convinced, _if_ you can make it work ;-)
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.
My thoughts exactly.
The frankendatetime should be a separate class that subclasses datetime.datetime, provides old-style DateTime compatability and has datetime.datetime-compatible pickles.
sounds good to me :-) cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk