On Nov 9, 2009, at 3:52 PM, Antoine Pitrou wrote:
Le lundi 09 novembre 2009 à 15:43 -0800, Kevin Teague a écrit :
Despite being such a bad
situation, the Plone core developers saw these warnings and did
nothing to fix them, they just learned to ignore the situation when
starting Plone - despite it being a major source of embarassment for
them, everyone just got used to ignoring them (until finally Hanno
took mercy and the led the charge to clean-up the morass).
So, the question is: would anyone have led the charge if there had
been
no visible warnings, and no morass to clean up? As an insider, what is
your thought about it?
The morass would have been cleaned up anyways, since the excessively
large amount of deprecations was acknowledged that Plone needed major
refactoring towards a cleaner code-base. I'm not exactly sure how much
the annoyance of the deprecations warnings played a role in
accelerating this - probably Hanno or Wichert would be better people
to ask. I only observed these warnings with annoyance since I only do
Plone work as an integrator (e.g. used Plone-as-framework).
Another thing that happened with all the deprecations in the Zope
world was DeprecationWarnings that had a long shelf life, generally a
couple of major releases, so around is three years or more. And at the
end of that point whomever initiated the deprecation is no longer
leading the charge for it, since they've moved on to other things. The
project itself shifted direction, and despite the deprecation
warnings, people would still use the old APIs (newbie developers) or
people would not want to go in and maintain their 3-year old code that
relyed on it and not want it to break needlessly. So there would be
opposition to removing the deprecation at that point. For example,
Zope 3.4 is the last proper Zope 3 release, but there are still
packages with deprecation warnings such as, "This function has been
deprecated and will go away in Zope 3.6." or "The ``localUtility``
directive has been deprecated and will be removed after 09/2007."
M.-A. Lemburg made a good point, "Don't raise the bar for warning
messages, raise the bar for deprecations themselves.". In Zope this
was generally adopted for many of those deprecations. Warnings were
spewed, people got annoyed, people lost interesting refactoring/
cleaning that particular code, and in the end after building up
"warnings immunity" it was agreed to just leave the BBB shims in
there ... they weren't hurting anything beyond adding a few kilobytes
to the size of the tarballs. (although there has been quite a bit of
movement just recently towards cleaning up the better packages from
Zope 3 and releasing them in the form of the Zope Toolkit).
As for me, I've become so blind to warnings that I couldn't tell you
of the top of my head if Python deprecated md5 -> hashlib or vice-
versa. Nor do I really care, I've never needed to interact with those
modules directly, but I've seen them spewed on the console a lot.
There are lots of cases where Python code is run on the command-line
and you aren't directly invoking it with the interpreter where you can
easily silence the warnings (although again, I've never bothered with
silencing them, I, like many, just learned to ignore them ... they're
annoying but not so annoying to want to have to rememeber to type
extra syntax every time you run the interpreter). Some notable command-
line Python apps where you can't easily put in a -W:
$ hg
$ buildout
$ pip
$ zopectl
$ paster
As for the code I write, I tend to favor packages outside the standard
library these days since they can move forward with refactoring in a
more timely manner, and I can make explicit those dependencies in the
setup.py's install_requires field. If a package requires 'argparse',
then it specifies that. If a package requires 'opster', then it
specifies that. No need for deprecation warnings saying argparse ->
opster or vice-versa. When the package is installed, it pulls in the
packages that it says that it needs. Simple as that.
But I don't think the DeprecationWarning discussion is entirely
fruitless. I'd imagine that Distutils in particular is going to need
to do some deprecations in order to make things "right" in packaging
land.
_______________________________________________
stdlib-sig mailing list
[email protected]
http://mail.python.org/mailman/listinfo/stdlib-sig
