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

[Brett Cannon]

On Mon, Nov 9, 2009 at 13:47, Antoine Pitrou <solipsis at pitrou.net> wrote:
>
>> First, there is the app user perspective. If I use an application I do
>> not need to see any warnings, ever.
>
> But most end users don't launch their applications via the command-line,
> so they won't get to see any stderr warnings anyway.
> (have you ever launched a Gnome or KDE app from the command-line? they
> can spout *tons* of warnings)

No, I haven't since I am a Mac user. But when I have launched Mac apps
from the command-line I have not had issues with warnings. Plus I do
launch plenty of command-line apps that could output warnings but
typically don't (but as I have said, this is not always the case when
I use a new interpreter on an app, e.g. Mercurial under 2.6 the day
Python 2.6 was released).

>
>> We cannot expect all developers to release a new
>> version just before or the day of a new interpreter release.
>
> And that's precisely why deprecation warnings are necessary to warn them
> beforehand. If you silence deprecation warnings by default,
> developers /will/ end up in situations where they have to do an
> emergency release to support the latest Python interpreter.
>

I don't quite follow that. If they hit deprecation warnings on a new
release and warnings are silent by default, how does that force an
emergency release? They just found out that the NEXT release of Python
will cause them trouble, not the new one that just came out.

> (OTOH, noisy deprecation warnings, however annoying they may be to you,
> don't force developers to do an emergency release in order to fix them;
> they allow developers to take their time)

Right, while I have to put up with them. As a user I don't want that.
If a Ruby app was spitting warnings out I would have to be searching
Google on how to turn them off and that's annoying.

>
>>  With the introduction of
>> __main__.py support for packages and zipfiles I can easily see people
>> starting to launch apps from the command-line with the newest
>> interpreter they have installed, e.g. ``python2.6 -m someapp``.
>
> Uh? These would be pretty advanced users. The "-m" option is certainly
> not known let alone used by the average non-Python savvy user.

At the moment. I know Paul Moore has said he wished more apps were
released this way as it is much easier to launch command-line apps
that way on Windows. Plus I released a zip file of an app like this
and have not had issues.

> And, of course, the Python savvy user is perfectly able to report a bug
> to the application developer.
>

But reporting a bug is not going to turn the warnings off. They still
have to be savvy enough to know to switch them off.

>> And
>> just because I have enough knowledge to know how to specify what
>> Python interpreter to use does not mean I care about warnings in
>> Python (might not even know how to program in Python), nor know about
>> the ``-W ignore`` trick (let alone want to have to type that every
>> time I use the app).
>
> This sounds really sophistic. If you know about "-m", you know to type
> "python --help" which immediately will give you the list of available
> options, including a possible "-W ignore", "-w" or whatever is added to
> that purpose.
>

Not if you are simply told "run this code using -m". And would you
really want to have to type ``-W ignore`` every time you ran an app? I
sure don't.

>> Some have said that there is
>> the possibility that they won't have the proper test coverage to pick
>> up the warnings. OK, fine, but that's not our problem.
>
> How condescending is that?

IMO it's not not meant to be. Sorry if you read it that way.

> Even /we/ are far from 100% test coverage.

I never claimed we had 100% coverage. But I would expect us all to be
running off of trunk for some things with warnings turned on.

>
>> Python has always been about
>> consenting adults.
>
> Being consenting adults, however, does not mean giving people a gun to
> shoot themselves in the foot, or removing any useful feature which might
> let them know that their code should be fixed. We may not be Java, but
> neither are we C++ or C.
>

This is obviously coming down to difference of opinion. I don't view
switching warnings off by default as shooting anyone in the foot. I
put it on the same level as making sure you have unit tests; it's just
part of your testing and verification process that your users just
don't need to know about.

>> If a development team does not dogfood their own
>> app with warnings turned on then that is their choice and they will be
>> bit in the ass at a later date. If a user gets bit by poor development
>> by a third-party that's unfortunate but once again not our fault since
>> we cannot dictate that people only use quality software.
>
> Brett, Python is a rich and diverse ecosystem. We as core developers may
> live in an ideal world where perfect development practices are followed
> (and even that is a lie, since we don't have 100% test coverage, some of
> our tests are flaky and our buildbots are often red), but our software
> is used in many situations, including by people (scientists, teachers,
> system administrators, webmasters) who are not professional Python
> programmers.

I know that. One of my best friends is a neurobiology PhD and they use
Python in her lab. They are not expert programmers. But if something
broke one day because they got a traceback which could have been
avoided had they turned on warnings I would hope they can figure out
how to fix that. Otherwise, warnings or not, they have bigger issues
to deal with.

>
>> In other words I think having warnings off by default is the best way
>> to improve the situation for users while still empowering developers
>> to know about things they need to change.
>
> Actually, it doesn't make the situation significantly better for users,
> or even for developers, it just satisfies our own little egoistical
> comfort as power users who don't like the annoying sight of warnings in
> a terminal.

I obviously disagree.

>
> I think this proposal is totally counter-productive, and counter to the
> idea that Python caters for diverse categories of developers.

Obviously we both are not about to change our minds on this one as we
are coming from different perspectives. So I agree that we disagree
and I am happy to leave it at that.

-Brett