On 3 March 2015 at 10:46, Giampaolo Rodola'
On Wed, Feb 25, 2015 at 8:51 AM, Serhiy Storchaka
wrote: What you are think about turning deprecation warnings on by default in the interactive interpreter?
Deprecation warnings are silent by default because they just annoys end user that uses old Python program with new Python. End user usually is not a programmer and can't do something with warnings. But in the interactive interpreter the user is the author of executed code and can avoid to use deprecated functions if warned.
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Am I the only one thinking that disabling deprecation warnings by default (2.6?) was a bad idea? It's particularly counterproductive for library vendors and their users because the latters have no visibility of what APIs are going to be removed: they will just wake up one day, upgrade to the next major version of their favorite lib and have their code broken.
Not really, because if you don't have automated regression tests, not seeing the deprecation warnings from your dependencies is the least of your worries - you can break your own stuff completely and have no idea until after you ship the broken version. If I ever find time to implement the PEP 432 changes to the startup sequence (or a volunteer interested in trying to unknot some of the most tangled C code we have left in the interpreter), then it might be feasible to introduce a system wide config file that redistributors and end users could use to decide whether to show deprecation warnings by default or not. In the meantime though, while the status quo has its flaws, I think its less flawed than the previous situation where end users were getting cryptic warnings they couldn't do anything about just because they were running a tool that happened to be written in Python (e.g. consider Mercurial users getting deprecation warnings on Python 2.6 when Python 2.7 was still over a year away). The previous approach was leading to things like tools explicitly silencing the warnings (so end users didn't see them), but then their tests weren't seeing them either. The flip in moving to the status quo (including adjusting test frameworks to turn the deprecation warnings back on) improved the situation for folks doing things right (i.e. using automated regression testing), while making it slightly worse for folks that are trusting to luck (i.e. they may not even get the deprecation warnings before things outright break on them). Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia