[Zope-dev] deprecating the deprecation system?

[Roger Ineichen]

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