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 ) > _______________________________________________ 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 )
