This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ncoghlan
Recipients dstufft, gvanrossum, hawkowl, ncoghlan, r.david.murray, serhiy.storchaka
Date 2017-10-10.13:09:52
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1507640992.54.0.213398074469.issue31742@psf.upfronthosting.co.za>
In-reply-to
Content
Deprecation warnings were different: we turned those off by default because currently working applications could start emitting console warnings simply because an end user ran them on a newer version of Python.

With future warnings, we're instead trying to detect cases where:

* a user has heard about a cool new Python standard library API, starts trying it out, but has no idea yet that it isn't covered by our regular backwards compatibility assurances. If they're a beginner or a corporation, this is setting them up for potential problems without any clear indication they might be doing something they may want to reconsider
* you upgraded a dependency and it started relying on a provisional API, and you'd prefer to stick with the old version rather than risking relying on the provisional interface

Neither of those situations can be encountered simply by running an existing *application* on a newer version of Python (assuming the application bundles all of its dependencies other than the runtime itself).

Neither of them is helped by an opt-in flag either, since the scenarios we're trying to detect include the affected user either:

1. Not knowing about provisional APIs at all;
2. Not knowing that *that particular* API is provisional; or
3. Not knowing that a dependency on that particular API has been introduced

Since the warning would be emitted through the regular warnings machinery, all those options would be available to turn it off, but there'd also be the even more convenient option of just setting "use_provisional_typing = True" in __main__ and leaving the warnings settings alone.

It's clear to me from both Guido's and David's confusion that this idea is going to need to go through the PEP process though, which is probably a reasonable thing to do anyway (since one of the outcomes would be an amendment to PEP 411 to include the programmatic warning mechanism).
History
Date User Action Args
2017-10-10 13:09:52ncoghlansetrecipients: + ncoghlan, gvanrossum, r.david.murray, serhiy.storchaka, dstufft, hawkowl
2017-10-10 13:09:52ncoghlansetmessageid: <1507640992.54.0.213398074469.issue31742@psf.upfronthosting.co.za>
2017-10-10 13:09:52ncoghlanlinkissue31742 messages
2017-10-10 13:09:52ncoghlancreate