[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