[Zope-dev] Deprecate ITerms in zope.app.form? [Re: zope.browser?]

[Tres Seaver]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martijn Faassen wrote:
> Marius Gedminas wrote:
>> On Tue, Dec 16, 2008 at 03:45:01PM -0500, Tres Seaver wrote:
> [why would we ever want to avoid giving deprecation warnings?]
>>> One issue is that adding deprecation messages for importing symbols from
>>> the old makes all "downstream" code add ugly BBB warts in order to
>>> suppress them when run against multiple versions.
>> Also consider deprecation messages triggered not by code, but by the use
>> in existing ZODB databases.  ISite is often directlyProvided by
>> persistent objects, which makes the ZODB store a fully-qualified
>> interface name.  You'd need an evolution script to walk the container
>> tree and force a repickling of every site to prevent the app from
>> spewing deprecation warnings at runtime.
> 
> I don't understand Tres' issue very well; I'm with Roger in that 
> deprecation warnings are there for a reason. That said if there's an 
> easier way to shut them up for people who don't want to bother with them 
> immediately that sounds reasonable. PendingDeprecationWarning as Brian 
> points out sounds like something we should look into.
> 
> The ZODB issue I do understand and perhaps that is the effect Tres is 
> pointing to as well. I hadn't realized that ISite was pickled 
> frequently. This may make it different from ITerms, which I assume isn't 
> generally pickled.
> 
> If we can get PendingDeprecationWarning working, people like Roger can 
> keep refactoring without bothering too many people and still get the 
> deprecation warnings they want to see. Then at some stage when a new 
> release of a framework (Zope 3, Grok, Zope 2) is made, we could convert 
> these warnings into true DeprecationWarnings and provide upgrade code 
> for ZODB-level code. Or even not - the Grok project could for instance 
> just have the policy not to release with any PendingDeprecationWarnings 
> present either.
> 
> For things we know never get pickled, we could choose to use 
> DeprecationWarning right away. This might run into Tres' issue, which I 
> don't quite understand yet. :)

I take cleaning up deprecation warnings seriously:  I want all tests for
my packages, for instance, to run without emitting *any* of them.
Deprecation warnings have a non-trivial downside:  consider the case
wher  one of *my* downstream users updates Roger's pacakge (e.g., to
pick up a critcial security fix, or something).  My package has
dependencies which allow this (because I don't put hard pins in library
packages), but now *my* package now emits warnings, where it didn't before.

In order to accomplish the goal of deprecation cleanliness, I can either:

 - Update my dependency requirements to point to only the newest
   versions of the code which adds the warnings.  My users are now
   forced to upgrade as well, which may cause their apps to break.

 - Add conditional imports to my code, which tries the "blessed"
   location first and then falls back to the "deprecated" location.
   This is the "cost transference" I was speaking of:  my code gets
   cruftier, just so Roger's can be "clean".

If we just leave the name importable from the old location, what is
hurt?  The major downside is that people won't learn about the new
location.  I consider this to be less an issue than the two problems I
outline above.  Even if the "pending warning" bit works, I still have to
add the BBB cruft to my code to future-proof it.


Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD4DBQFJSY0F+gerLs4ltQ4RAqkNAJ9BcBPXiW3jZBv2hInmvLeUEdajUACYxZh+
PlGE+sB2GloP2iyl/yW+aw==
=ygv/
-----END PGP SIGNATURE-----