[stdlib-sig] standardizing the deprecation policy (and how noisy they are)

[nathan binkert]

>> (Another argument to think about: if you download and install some 3rd
>> party code, deprecation warnings about that code are *only noise*
>> since they are not yours to fix. Warnings in a dynamic language work
>> very different than warnings in a compiled language.)
>
> That's very true. Until Mercurial caught up to Python 2.6 the sha/md5
> warnings were very annoying. I actually modified my copy to turn them
> off myself.

I too find this sort of thing very annoying. Perhaps we should teach
people to install their programs with
#!/usr/bin/python -W ignore

This way pending deprecations are on by default, but people that
install programs will not have them.

Even better would be some sort of "release mode" argument (e.g. "-R")
to python.  That could turn off pending deprecation warnings and
perhaps other things that fall into a similar category (maybe to allow
an app developer to choose between tracebacks or not depending on the
value of this flag).    Still better if setuptools knew about the
release mode so developers would not use it and get the warnings, but
people installing it would.

I have no idea how this would be done in windows.

I'm not offering patches though, so I'll shut up now.

  Nate