[Python-ideas] Show deprecation warnings in the interactive interpreter

[Nick Coghlan]

On 3 March 2015 at 10:46, Giampaolo Rodola' <g.rodola at gmail.com> wrote:
>
>
> On Wed, Feb 25, 2015 at 8:51 AM, Serhiy Storchaka <storchaka at gmail.com>
> 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 at 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 at gmail.com   |   Brisbane, Australia