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. * 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. * 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've not been very good at removing old deprecations over time. * 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. * 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. :) Thoughts? Regards, Martijn