[issue31742] Default to emitting FutureWarning for provisional APIs

Change by Ethan Furman : -- nosy: +ethan.furman ___ Python tracker ___ ___

[issue31742] Default to emitting FutureWarning for provisional APIs

Guido van Rossum added the comment: OK, I'll wait for the new PEP and ignore the ticket. -- ___ Python tracker ___

[issue31742] Default to emitting FutureWarning for provisional APIs

Change by Guido van Rossum : -- nosy: -gvanrossum ___ Python tracker ___ ___

[issue31742] Default to emitting FutureWarning for provisional APIs

Nick Coghlan added the comment: OK, I'll head down the path of creating a new procedural PEP to supersede PEP 411 (I'll try to get the locals() semantic clarification PEP out of the way first, though). I'll make "Where to put the feature flags?" an open question, as my

[issue31742] Default to emitting FutureWarning for provisional APIs

Aaron Gallagher <_...@habnab.it> added the comment: >Storing the marker attribute in __main__ [...] Can I request please not using __main__ for this? setuptools console_scripts are very common, which is a case where __main__ will be a generated (i.e. not user-controllable) file. Making

[issue31742] Default to emitting FutureWarning for provisional APIs

Guido van Rossum added the comment: I think this ought to be a new PEP which supersedes PEP 411. I think it should simply *offer* the option of using a feature flag rather than prescribing it. It could also explain that feature flags could cover an entire module or only the

[issue31742] Default to emitting FutureWarning for provisional APIs

Nick Coghlan added the comment: Keep in mind that I'm not proposing that we retroactively change our approach to managing any currently provisional APIs that were proposed and implemented under the current version of PEP 411. Instead I'm merely suggesting that the policy

[issue31742] Default to emitting FutureWarning for provisional APIs

Guido van Rossum added the comment: I am at a loss for words. On Oct 12, 2017 6:27 PM, "Nick Coghlan" wrote: > > Nick Coghlan added the comment: > > If a proposed standard library API is sufficiently stable that the folks >

[issue31742] Default to emitting FutureWarning for provisional APIs

Nick Coghlan added the comment: If a proposed standard library API is sufficiently stable that the folks proposing it are reluctant to emit a runtime warning about any remaining stability risks, then I think it's reasonable to expect them to propose it as non-provisional

[issue31742] Default to emitting FutureWarning for provisional APIs

Ned Deily added the comment: Besides making the provisional warning more noticeable in module doc pages, perhaps we should have a "Provisional Package / API" section somewhere in the release's docset: a liat of all provisionals and perhaps a list of formerly provisional, now

[issue31742] Default to emitting FutureWarning for provisional APIs

Guido van Rossum added the comment: OK, so the Django and Twisted developers had to resist some pressure from their users. These are mature projects and if they can't resist pressure from users something is wrong with those projects, and just pointing users to PEP 411 would

[issue31742] Default to emitting FutureWarning for provisional APIs

Change by Ned Deily : -- nosy: +ned.deily ___ Python tracker ___ ___ Python-bugs-list

[issue31742] Default to emitting FutureWarning for provisional APIs

Amber Brown added the comment: > * asyncio & pathlib are already non-provisional, so wouldn't be affected. I was reading this and actually said "wait what I didn't know pathlib was provisional", and went back to check. The warning for it was grey next to a pair of

[issue31742] Default to emitting FutureWarning for provisional APIs

Nick Coghlan added the comment: A note regarding applicability if we did make a change to our approach: * asyncio & pathlib are already non-provisional, so wouldn't be affected. * typing is still provisional, but introducing a new FutureWarning after two releases without

[issue31742] Default to emitting FutureWarning for provisional APIs

Guido van Rossum added the comment: I'm still trying to understand whether there's a specific event (or set of events) that's triggered this issue. There is a lot of talk about people can be misled but not a single specific example of someone who actually got in trouble

[issue31742] Default to emitting FutureWarning for provisional APIs

Amber Brown added the comment: > What happened to "consenting adults"? Consent does not mean that by using Python, users fully consent to using modules that they may not be aware will, to paraphrase Donald, come back to bite them in the ass. Consent requires

[issue31742] Default to emitting FutureWarning for provisional APIs

Donald Stufft added the comment: > What happened to "consenting adults"? Making sure they're actually consenting when getting into something that might potentially bite them in the ass seems like a sane and thoughtful thing to do to me. --

[issue31742] Default to emitting FutureWarning for provisional APIs

Guido van Rossum added the comment: I have no bandwidth for this discussion, but so far I am not convinced. What happened to "consenting adults"? > [...] the entire point of the proposed warning letting people know that they > may be using something they are not fully

[issue31742] Default to emitting FutureWarning for provisional APIs

Nick Coghlan added the comment: The deprecation warnings weren't turned off due to Python developers running things in virtual environments - they were turned off due to Linux distros upgrading their system Python runtimes, and Linux ISVs getting an influx of new bug

[issue31742] Default to emitting FutureWarning for provisional APIs

Nick Coghlan added the comment: A note regarding *only* using the warnings module to turn things off: The problem I have with that is that the UX is relatively clumsy, and hence runs into the concern Guido mentions above: "having this warning pop up every time you import

[issue31742] Default to emitting FutureWarning for provisional APIs

R. David Murray added the comment: Nick says: "Neither of those situations can be encountered simply by running an existing *application* on a newer version of Python". I fail to see the operational difference between running an application on a newer version of

[issue31742] Default to emitting FutureWarning for provisional APIs

R. David Murray added the comment: I imagine we could make it controlled by the same setting that controls deprecation warnings, with some way to differentiate them if you really need to. I forget exactly how that warning control works, so maybe that would be awkward,

[issue31742] Default to emitting FutureWarning for provisional APIs

Nick Coghlan added the comment: 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

[issue31742] Default to emitting FutureWarning for provisional APIs

Amber Brown added the comment: So you're proposing a coordinated effort across the half dozen, possibly more, test runners to enable some flags, so CPython doesn't log a single message, possibly two, that you're using unsupported experimental software with no

[issue31742] Default to emitting FutureWarning for provisional APIs

Serhiy Storchaka added the comment: I don't think that a special way for silencing FutureWarning is needed. You can use an existing mechanism. import warnings warnings.filterwarnings('ignore', '', FutureWarning, 'typing') -- nosy:

[issue31742] Default to emitting FutureWarning for provisional APIs

R. David Murray added the comment: That's why I said set on by default by the test harnesses. The opt in would be done by the standard testing tools, not directly by the programmer. That's how deprecation warnings work now. --

[issue31742] Default to emitting FutureWarning for provisional APIs

Amber Brown added the comment: What is the point of an opt-in warning, when the entire point of the proposed warning is letting people know that they may be using something they are not fully educated or informed about the ramifications of using? If you know to

[issue31742] Default to emitting FutureWarning for provisional APIs

R. David Murray added the comment: I think there needs to be an easy way to turn off the warnings while running tests, as well. I don't want to be bothered by those messages when testing parts of my package that are consciously using the provisional features. But

[issue31742] Default to emitting FutureWarning for provisional APIs

Nick Coghlan added the comment: I think if someone is going to be put off by a FutureWarning, then that indicates they're not yet familiar with just what the provisional API status means, and those are exactly the folks we *want* to scare away from provisional APIs (or

[issue31742] Default to emitting FutureWarning for provisional APIs

Amber Brown added the comment: Donald hits it on the head for me. As long as the code is not covered by the same API deprecation contract that the rest of the standard library is, it should make it obvious when attempting to use it. I can be relatively certain that

[issue31742] Default to emitting FutureWarning for provisional APIs

Donald Stufft added the comment: The fundamental problem is that unless you're closely following the development of python-dev, it's really really easy to use a provisional module without knowing that you are. Take asyncio for example, as far as I can tell the documentation

[issue31742] Default to emitting FutureWarning for provisional APIs

Guido van Rossum added the comment: While I understand the sentiment, having this warning pop up every time you import a provisional module while developing code feels like harassment of the very users we'd like to try out the provisional APIs. It's also too course-grained

[issue31742] Default to emitting FutureWarning for provisional APIs

Nick Coghlan added the comment: This is also fairly similar to Rust's approach of using feature flags to explicitly opt-in to unstable features: https://doc.rust-lang.org/unstable-book/ -- ___ Python tracker

[issue31742] Default to emitting FutureWarning for provisional APIs

Nick Coghlan added the comment: Another advantage of this approach: anyone running their tests in a "no warnings allowed" configuration would get a hard failure when dependencies on a provisional API were unexpectedly introduced (e.g. when updating a third party library),

[issue31742] Default to emitting FutureWarning for provisional APIs

New submission from Nick Coghlan : Chatting to Donald Stufft and Amber Brown about the way we currently handle provisional APIs, I think they have a legitimate concern that we may not be gathering adequately informed consent from users when they depend on APIs that we've