Re: [Zope-dev] Deprecate ITerms in zope.app.form? [Re: zope.browser?]
On Wed, Dec 17, 2008 at 6:36 PM, Tres Seaver wrote: > 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. Agreed. Moving things around in public packages without preserving backward compatibility creates real nuisances, and just not generating warnings avoids lots of pain. This doesn't mean that you can't teach people about new locations; you just don't need to do it every time they run your code. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ 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 )
Re: [Zope-dev] SVN: z3c.formjs/tags/0.4.1/ Tag 0.4.1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christian Theune wrote: > On Tue, 2008-12-16 at 04:30 -0500, Dan Korostelev wrote: >> Log message for revision 94108: >> Tag 0.4.1 >> >> Changed: >> A z3c.formjs/tags/0.4.1/ >> U z3c.formjs/tags/0.4.1/CHANGES.txt >> U z3c.formjs/tags/0.4.1/setup.py > > Interesting. Did you achieve this in a single transaction by creating > the tag on your hard drive first? I've seen this style of output also when using 'svn cp . $TAGPATH'. - -- === Tres Seaver +1 540-429-0999 tsea...@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 iD8DBQFJSY6N+gerLs4ltQ4RAlygAJsGhj/UV2cKlTKc7DWQtXjUfm8MCgCgvLfh KkjRwKmaMu/Vt9eJUVXIxsM= =Lw8S -END PGP SIGNATURE- ___ 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 )
Re: [Zope-dev] Deprecate ITerms in zope.app.form? [Re: zope.browser?]
-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 tsea...@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- ___ 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 )
Re: [Zope-dev] Deprecate ITerms in zope.app.form? [Re:zope.browser?]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Roger Ineichen wrote: > Hi Tres > >> Betreff: Re: [Zope-dev] Deprecate ITerms in zope.app.form? >> [Re:zope.browser?] > > [...] > >> 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. > > Yes, that's exactly what deprecation message do. Deprecation > messages in tests do not have to win a beauty award. The goal > of a deprecation message is to inform developers about upcomming > changes. This ugly BBB output is very important to me! > > This allows us to schedule our work and we don't run into > removed backward compatibility issues. This makes deprecation > messages something like a reminder and nothing which we should > ignore. > > If we don't use deprecation messages we can not do future cleanup > because we can't remove old not deprecated code. > > This means using deprecation message or not depends on the need > for a future cleanup. If we like to support an old interface > location then we don't need deprecation messages. But if we > like to remove the interface at the old location in the future > then we need to deprecate them. This has nothing to do with > beautify our test output. I think you missed my point: third-party developers who want their code *not* to emit the deprecation warnings when used across both old and new versions of "our" library have to add nasty BBB cruft to *their* code: we've shifted the BBB burden to them, often for a small marginal benefit to ourselves. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@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 iD8DBQFJSUMo+gerLs4ltQ4RAuncAKCS9HL5XlvjHQoI1Y/6IwVJ2+c7iACfSFcj wyqDo/8Qgd1Om79oyLjy7yA= =kenJ -END PGP SIGNATURE- ___ 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 )
Re: [Zope-dev] Deprecate ITerms in zope.app.form? [Re: zope.browser?]
On Wed, Dec 17, 2008 at 8:31 AM, Martijn Faassen wrote: > 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. :) > > How does that sound? Even though I don't mind deprecation warnings as they are, a provisional +1 from me; I too would like to hear more about Tres' scenario. -- Benji York Senior Software Engineer Zope Corporation ___ 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 )
Re: [Zope-dev] Deprecate ITerms in zope.app.form? [Re: zope.browser?]
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. :) How does that sound? 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] Zope Tests: 4 OK, 2 Failed
Summary of messages to the zope-tests list. Period Tue Dec 16 12:00:00 2008 UTC to Wed Dec 17 12:00:00 2008 UTC. There were 6 messages: 6 from Zope Tests. Test failures - Subject: FAILED (failures=2) : Zope-trunk Python-2.4.5 : Linux From: Zope Tests Date: Tue Dec 16 20:36:31 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-December/010667.html Subject: FAILED (failures=2) : Zope-trunk Python-2.5.2 : Linux From: Zope Tests Date: Tue Dec 16 20:38:01 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-December/010668.html Tests passed OK --- Subject: OK : Zope-2.8 Python-2.3.7 : Linux From: Zope Tests Date: Tue Dec 16 20:30:30 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-December/010663.html Subject: OK : Zope-2.9 Python-2.4.5 : Linux From: Zope Tests Date: Tue Dec 16 20:32:00 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-December/010664.html Subject: OK : Zope-2.10 Python-2.4.5 : Linux From: Zope Tests Date: Tue Dec 16 20:33:30 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-December/010665.html Subject: OK : Zope-2.11 Python-2.4.5 : Linux From: Zope Tests Date: Tue Dec 16 20:35:00 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-December/010666.html ___ 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 )
Re: [Zope-dev] Deprecate ITerms in zope.app.form? [Re: zope.browser?]
On Tue, Dec 16, 2008 at 03:45:01PM -0500, Tres Seaver wrote: > Martijn Faassen wrote: > > Christian Zagrodnick wrote: > > [snip] > >> Nope. http://mail.zope.org/pipermail/zope3-dev/2007-August/023223.html > > > > Weird. At first glance I do not understand the context of that decision. > > There was a decision to "avoid deprecation" made by it doesn't seem to > > be motivated in the discussion: > > > > "- zope.app.component.interfaces then can import ISite from the new > > place to avoid deprectation." > > > > You're saying, I think, that we should do the same thing as in that > > discussion to avoid deprecation too. But I cannot find a reason to avoid > > deprecation in the original discussion. Could you elaborate on your > > thinking? > > > > I'm hoping to soon go through quite a few packages and deprecate lots of > > stuff by moving it into other packages to try to tidy up the dependency > > structure. If there are important arguments against deprecation warnings > > I'd like to understand the background. > > 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. Regards, -- http://pov.lt/ -- Zope 3 consulting and development signature.asc Description: Digital signature ___ 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 )
Re: [Zope-dev] Deprecate ITerms in zope.app.form? [Re: zope.browser?]
On Tue, Dec 16, 2008 at 03:45:01PM -0500, Tres Seaver wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Martijn Faassen wrote:
> > Christian Zagrodnick wrote:
> > [snip]
> >> Nope. http://mail.zope.org/pipermail/zope3-dev/2007-August/023223.html
> >
> > Weird. At first glance I do not understand the context of that decision.
> > There was a decision to "avoid deprecation" made by it doesn't seem to
> > be motivated in the discussion:
> >
> > "- zope.app.component.interfaces then can import ISite from the new
> > place to avoid deprectation."
> >
> > You're saying, I think, that we should do the same thing as in that
> > discussion to avoid deprecation too. But I cannot find a reason to avoid
> > deprecation in the original discussion. Could you elaborate on your
> > thinking?
> >
> > I'm hoping to soon go through quite a few packages and deprecate lots of
> > stuff by moving it into other packages to try to tidy up the dependency
> > structure. If there are important arguments against deprecation warnings
> > I'd like to understand the background.
>
> 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.
This is my issue as well.
http://docs.python.org/library/warnings.html#module-warnings
We could use PendingDeprecationWarning for recently deprecated code and
then convert that to DeprecationWarning once an alternative has been
available for some time.
That way, people like Roger would be able to get all recent deprecation
warnings by using the -Wd command line option to python, but they
wouldn't be shown by default.
# python2.4 -Wd
>>> import warnings
>>> warnings.warn("deprecated", PendingDeprecationWarning)
__main__:1: PendingDeprecationWarning: deprecated
# python2.4
>>> import warnings
>>> warnings.warn("deprecated", PendingDeprecationWarning)
There's probably some caveat as to why this won't work, but it seems
like it should by looking at the documentation.
--
Brian Sutherland
___
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 )
