[stdlib-sig] standardizing the deprecation policy (and hownoisy they are)
Leonardo Santagada
santagada at gmail.com
Tue Nov 10 16:54:28 CET 2009
On Nov 10, 2009, at 1:28 PM, Antoine Pitrou wrote:
> That's why it is advised to report the problem to the maintainer (or
> perhaps the packager, in case e.g. of a linux distro), like you do for
> any other bug.
So what you are saying is that all python app developer should receive
hundreds of bug reports (or at least "me too" comments) for months if
he decides that he has other priorities than to fix deprecation
warnings?
There is a reason it takes more than a year to remove something from
the language and that is so that people can adapt on their own time,
so you are either saying that users should ignore errors (giving way
to Laura's argument) or that they should be bullied by its users. Or
are you suggesting that the default should be warnings on and everyone
should release their software with code to turn it off?
If I could vote I would be +1 on the idea of warnings off and moving
that to pylint or some other tool, but with a good paragraph or two on
the docs about it. Or a switch to turn warnings on with an api so that
unittest and py.test could turn them on.
--
Leonardo Santagada
santagada at gmail.com
More information about the stdlib-sig
mailing list