Hi Martijn
Betreff: [Zope-dev] deprecating the deprecation system?
Hi there,
Perhaps it's time to deprecate the deprecation system.
Why?
* I've had good experience in the Grok project with just noting changes that might break code in the upgrade notes for Grok and telling people how to fix it. Using documentation more background can be provided and it can become a lot more clear what to do.
It is always good to have such a documentation. But what does this have to do with removing a deprecation system?
* using the deprecation system requires quite a bit of effort, as we're adding code. Do we test deprecations? That's quite a bit of energy spent there that we could instead spend on documentation.
Yes, a deprecation system requires a lot of effort but that doesn't mean that the deprecation system is bad or good. I personaly think it's harder for me to write a good english documentation in the same time. But that's probably because I never learned english.
* it's a zope-specific system no other Python projects use. Now we'll need some of them, but do we need this one?
We have many things in zope which others don't use. That's no mesuring base for good or bad
* we've not been very good at removing old deprecations over time.
we can do it better
* the deprecation system's messages have traditionally not been of a high quality. I recall occasions where it told me half of what to do, and certainly won't give me any background on what is going on.
a unclear message is even better then no message
* for moving code around we have an alternative system: a backwards compatibility import, documentation about what to do, and a tool part of the test runner which can point out indirect imports.
I therefore propose we do the following:
* look at any package which uses deprecation warnings now.
* rip out the deprecation warnings and backwards compatibility code. Even if it's really expiring in 2010 (I doubt we have much of this). When you do so and you think anyone might still using that code path, please make a remark in zope3docs/source/migration/34to35.rst about what's going on and what people are to do.
* run the compattests to see whether anything breaks. I think it's quite possible some deprecated code is in use by the Zope libraries themselves. :)
I'm a little bit skeptic about this proposal. And I think no reason you listed does really explain why the deprecation system is bad. The only reason to use a deprecation system is to ensure that there is a deprecation period. I think the (real) reason why we can't use a deprecation system is that we don't like to support a deprecation period anymore because we like to evolve our package in a incompatible way now and not later. This makes our deprecation system useless and a migration path document is the only solution to handle that. Any other reason not using a deprecation system is just based on to less available time to support it or lazyness. btw, Right now it's very unclear how we identify versions like 3.4 / 3.5 What does that mean since packages have it's own versions e.g. 3.7.5 and are release within 3.4. How do you identify the zope version (3.4/3.5) of such a package?
Thoughts?
+/- 0 I let me surprise, let's try something new. We can still fallback to a deprecation system if everything else fails. Regards Roger Ineichen
Regards,
Martijn
_______________________________________________ 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 )