> Betreff: [Zope-dev] deprecating the deprecation system?
> Hi there,
> Perhaps it's time to deprecate the deprecation system.
> * 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.
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?
I let me surprise, let's try something new. We can still
fallback to a deprecation system if everything else fails.
> Zope-Dev maillist - Zope-Dev@zope.org
> ** No cross posts or HTML encoding! ** (Related lists -
> http://mail.zope.org/mailman/listinfo/zope )
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -