Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

On 11 November 2017 at 02:02, Random832 wrote: > On Tue, Nov 7, 2017, at 07:22, Nick Coghlan wrote: >> My suggestion for that definition is to have the *default* meaning of >> "third party code" be "everything that isn't __main__". > > What is __main__? Or, rather, how do you determine when it is

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

On Tue, Nov 7, 2017, at 07:22, Nick Coghlan wrote: > My suggestion for that definition is to have the *default* meaning of > "third party code" be "everything that isn't __main__". What is __main__? Or, rather, how do you determine when it is to blame? For syntax it's easy, but any deprecated func

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

On Tue, Nov 7, 2017 at 8:45 AM, Nathaniel Smith wrote: > Also, IIRC it's actually impossible to set the stacklevel= correctly when > you're deprecating a whole module and issue the warning at import time, > because you need to know how many stack frames the import system uses. Doh, I didn't remem

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

Ethan Furman writes: > Suffering from DeprecationWarnings is not "being hosed". Having > your script/application/framework suddenly stop working because > nobody noticed something was being deprecated is "being hosed". OK, so suffering from DeprecationWarnings is not "being hosed". Neverthele

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

On 9 November 2017 at 04:56, Barry Warsaw wrote: > On Nov 8, 2017, at 08:47, Guido van Rossum wrote: >> >> You seem to have missed Nick's posts where he clearly accepts that a middle >> ground is necessary. R D Murray is also still unconvinced. (And obviously I >> myself am against reverting to

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

On Nov 8, 2017, at 12:02, Guido van Rossum wrote: > > I hadn't seen that, but it requires too much cooperation of library owners. Actually, mostly just setuptools and as Paul points out, pip. Cheers, -Barry signature.asc Description: Message signed with OpenPGP __

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

On 8 November 2017 at 18:56, Barry Warsaw wrote: > On Nov 8, 2017, at 08:47, Guido van Rossum wrote: >> >> You seem to have missed Nick's posts where he clearly accepts that a middle >> ground is necessary. R D Murray is also still unconvinced. (And obviously I >> myself am against reverting to

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

I hadn't seen that, but it requires too much cooperation of library owners. On Wed, Nov 8, 2017 at 10:56 AM, Barry Warsaw wrote: > On Nov 8, 2017, at 08:47, Guido van Rossum wrote: > > > > You seem to have missed Nick's posts where he clearly accepts that a > middle ground is necessary. R D Mur

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

On Nov 8, 2017, at 08:47, Guido van Rossum wrote: > > You seem to have missed Nick's posts where he clearly accepts that a middle > ground is necessary. R D Murray is also still unconvinced. (And obviously I > myself am against reverting to the behavior from 7 years ago.) If we can't > agree o

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

Philipp, You seem to have missed Nick's posts where he clearly accepts that a middle ground is necessary. R D Murray is also still unconvinced. (And obviously I myself am against reverting to the behavior from 7 years ago.) If we can't agree on some middle ground, the status quo will be maintained

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

Hi Guido, As far as I can see, the general consensus seems to be to turn them back on in general: The last person to argue against it was Paul Moore, and he since said: “OK, I overstated [that you’re ‘hosed’ by DeprecationWarnings appearing]. Apologies. My recollection is of a lot more end user c

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

Sorry - trigger happy on the previous message. On 6 November 2017 at 05:09, Guido van Rossum wrote: > I still find this unfriendly to users of Python scripts and small apps who > are not the developers of those scripts. (Large apps tend to spit out so > much logging it doesn't really matter.) > >

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

On 6 November 2017 at 05:09, Guido van Rossum wrote: > I still find this unfriendly to users of Python scripts and small apps who > are not the developers of those scripts. (Large apps tend to spit out so > much logging it doesn't really matter.) > > Isn't there a better heuristic we can come up w

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

To cut this thread short, I say we should use Nick's proposal to turn these warnings on for __main__ but off elsewhere. (See https://mail.python.org/pipermail/python-dev/2017-November/150364.html.) -- --Guido van Rossum (python.org/~guido) ___ Python-De

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

Antoine Pitrou wrote: > On Mon, 6 Nov 2017 23:23:25 +1000 >> - tweak the default warning filters to turn DeprecationWarning back on >> for __main__ only > > Thats sounds error-prone. I'd rather have them on by default > everywhere. If DeprecationWarnings were on by default, and setuptools were m

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

On Nov 7, 2017, at 13:34, Jakub Wilk wrote: > "import async" would indeed cause deprecation warning, but that's not what > ldap3 does. The only uses of the now-keyword "async" in their codebase are > like this: > > from ..strategy.async import AsyncStrategy > from .async import AsyncStrategy

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

* Barry Warsaw , 2017-11-06, 15:56: We also depend on ldap3 . Suddenly we get a SyntaxError because ldap3 has a module ldap3/strategy/async.py. I say "suddenly" because of course *if* DeprecationWarnings had been enabled by default, I'm sure someone would have n

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

On 2017-11-07 14:17, Philipp A. wrote: Nick Coghlan mailto:ncogh...@gmail.com>> schrieb am Di., 7. Nov. 2017 um 14:57 Uhr: Users of applications written in Python are not python-dev's users: they're the users of those applications, and hence the quality of that experience is up to t

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

On 8 November 2017 at 03:55, Barry Warsaw wrote: > On Nov 7, 2017, at 05:44, Paul Moore wrote: > > > If you're a user and your application developer didn't do (1) or a > > library developer developing one of the libraries your application > > developer chose to use didn't do (2), you're hosed. I

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

On Nov 7, 2017, at 05:44, Paul Moore wrote: > If you're a user and your application developer didn't do (1) or a > library developer developing one of the libraries your application > developer chose to use didn't do (2), you're hosed. If you're a user > who works in an environment where moving t

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

On Nov 7, 2017 06:24, "Nick Coghlan" wrote: On 7 November 2017 at 19:30, Paul Moore wrote: > On 7 November 2017 at 04:09, Nick Coghlan wrote: >> Given the status quo, how do educators learn that the examples they're >> teaching to their students are using deprecated APIs? > > By reading the doc

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

On Nov 7, 2017 5:47 AM, "Paul Moore" wrote: On 7 November 2017 at 13:35, Philipp A. wrote: > Sorry, I still don’t understand how any of this is a problem. > > If you’re an application developer, google “python disable > DeprecationWarning” and paste the code you found, so your users don’t see >

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

On 7 November 2017 at 14:21, Ethan Furman wrote: > On 11/07/2017 05:44 AM, Paul Moore wrote: > >> If you're a user and your application developer didn't do (1) or a >> library developer developing one of the libraries your application >> developer chose to use didn't do (2), you're hosed. If you'r

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

On 11/07/2017 05:44 AM, Paul Moore wrote: If you're a user and your application developer didn't do (1) or a library developer developing one of the libraries your application developer chose to use didn't do (2), you're hosed. If you're a user who works in an environment where moving to a new v

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

Nick Coghlan schrieb am Di., 7. Nov. 2017 um 14:57 Uhr: > Users of applications written in Python are not python-dev's users: > they're the users of those applications, and hence the quality of that > experience is up to the developers of those applications. […] > Thank you, that’s exactly what

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

On 7 November 2017 at 23:44, Paul Moore wrote: > As I say, the proposal prioritises developer convenience over end user > experience. Users of applications written in Python are not python-dev's users: they're the users of those applications, and hence the quality of that experience is up to the

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

On 7 November 2017 at 13:35, Philipp A. wrote: > Sorry, I still don’t understand how any of this is a problem. > > If you’re an application developer, google “python disable > DeprecationWarning” and paste the code you found, so your users don’t see > the warnings. > If you’re a library developer,

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

Sorry, I still don’t understand how any of this is a problem. 1. If you’re an application developer, google “python disable DeprecationWarning” and paste the code you found, so your users don’t see the warnings. 2. If you’re a library developer, and a library you depend on raises De

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

On 7 November 2017 at 19:30, Paul Moore wrote: > On 7 November 2017 at 04:09, Nick Coghlan wrote: >> Given the status quo, how do educators learn that the examples they're >> teaching to their students are using deprecated APIs? > > By reading the documentation on what they are teaching, and by t

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

On Tue, 7 Nov 2017 09:30:19 + Paul Moore wrote: > > I understand the "but no-one actually does this" argument. And I > understand that breakage as a result is worse than a few warnings. But > enabling deprecation warnings by default feels to me like favouring > the developer over the end user

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

On 7 November 2017 at 04:09, Nick Coghlan wrote: > Given the status quo, how do educators learn that the examples they're > teaching to their students are using deprecated APIs? By reading the documentation on what they are teaching, and by testing their examples with new versions with deprecatio

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

On 7 November 2017 at 03:42, Simon Cross wrote: > Maybe there are ways around these things, but I'm not really seeing > what's wrong with the current situation that can't be fixed with > slightly better CI setups (which are good for other reasons too). Given the status quo, how do educators learn

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

On 11/6/2017 1:12 PM, Barry Warsaw wrote: On Nov 5, 2017, at 20:47, Nick Coghlan wrote: warnings.silence_deprecations() python -X silence-deprecations PYTHONSILENCEDEPRECATIONS=x It could be interesting to combine this with Tim's suggestion of putting an upper version limit on the silencing,

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

Nick Coghlan wrote: > On the 12-weeks-to-3.7-feature-freeze thread, Jose Bueno & I both > mistakenly though the async/await deprecation warnings were missing > from 3.6. Sometimes the universe just throws synchronicity right in your face. I'm working on building an internal tool against Python 3.

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

On Mon, 6 Nov 2017 at 00:30 Victor Stinner wrote: > 2017-11-06 8:47 GMT+01:00 Serhiy Storchaka : > > 06.11.17 09:09, Guido van Rossum пише: > >> > >> I still find this unfriendly to users of Python scripts and small apps > who > >> are not the developers of those scripts. (Large apps tend to spit

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

On Nov 5, 2017, at 20:47, Nick Coghlan wrote: >> warnings.silence_deprecations() >> python -X silence-deprecations >> PYTHONSILENCEDEPRECATIONS=x > > It could be interesting to combine this with Tim's suggestion of > putting an upper version limit on the silencing, so the above may look > like:

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

On Nov 5, 2017, at 23:08, Serhiy Storchaka wrote: > Following issues on GitHub related to new Python releases I have found that > many projects try to fix deprecation warning, but there are projects that are > surprised by ending of deprecation periods and removing features. Like others here,

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

I'm -1 on turning this on by default. As a Python developer, I want to be aware of when deprecations are introduced, but I don't want the users of my library or application to care or know if I don't address those deprecation warnings for a few months or a year. The right solution for me here seem

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

On 6 November 2017 at 14:16, Gustavo Carneiro wrote: > But eventually, the warnings in 3rd-party Python modules gradually increased > because, since warnings are disabled by default, authors of command-line > tools, or even python modules, don't even realise they are triggering the > warning. > >

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

Hi! Just this minute I ran across a case where I’d want DeprecationWarnings on by default (We want to rename a property in an API I’m co-developing. I has mainly scientists as target audience, so end users, not developers) Gustavo Carneiro schrieb am Mo., 6. Nov. 2017 um 15:19 Uhr: > Big +1 to

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

Big +1 to turning warnings on by default again. When this behaviour first started, first I was surprised, then annoyed that warnings were being suppressed. For a few years I learned to have `export PYTHONWARNINGS=default` in my .bashrc. But eventually, the warnings in 3rd-party Python modules gr

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

On Mon, 6 Nov 2017 23:23:25 +1000 Nick Coghlan wrote: > On 6 November 2017 at 21:58, Antoine Pitrou wrote: > > I guess my takeaway point is that many situations are complicated, and > > many third-party library developers are much less disciplined than what > > some of us would idealistically exp

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

On 6 November 2017 at 21:58, Antoine Pitrou wrote: > I guess my takeaway point is that many situations are complicated, and > many third-party library developers are much less disciplined than what > some of us would idealistically expect them to be (those developers > probably often have good rea

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

On Mon, 6 Nov 2017 12:45:27 +0100 Antoine Pitrou wrote: > > I'm on the fence on this. > > I was part of the minority who opposed the original decision. So I > really appreciate your sentiment. Since then, I had to deal with a lot > of very diverse third-party libraries, and I learned that: >

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

On Mon, 6 Nov 2017 12:05:07 +1000 Nick Coghlan wrote: > > So my proposal is simple (and not really new): let's revert back to > the way things were in 2.6 and earlier, with DeprecationWarning being > visible by default, and app devs having to silence it explicitly > during application startup (be

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

On 6 November 2017 at 20:21, Paul Moore wrote: > On 6 November 2017 at 03:38, Nick Coghlan wrote: >> - if we ever write "import foo" ourselves, then we're a Python >> developer, and it's our responsibility to work out how to manage >> DeprecationWarning when it gets raised by either our own code,

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

On 6 November 2017 at 03:38, Nick Coghlan wrote: > - if we ever write "import foo" ourselves, then we're a Python > developer, and it's our responsibility to work out how to manage > DeprecationWarning when it gets raised by either our own code, or the > libraries and frameworks that we use As so

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

2017-11-06 8:47 GMT+01:00 Serhiy Storchaka : > 06.11.17 09:09, Guido van Rossum пише: >> >> I still find this unfriendly to users of Python scripts and small apps who >> are not the developers of those scripts. (Large apps tend to spit out so >> much logging it doesn't really matter.) >> >> Isn't t

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

On Sun, Nov 5, 2017 at 9:38 PM, Nick Coghlan wrote: > We've been running the current experiment for 7 years, and the main > observable outcome has been folks getting surprised by breaking > changes in CPython releases, especially folks that primarily use > Python interactively (e.g. for data analy

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

On 6 November 2017 at 17:09, Guido van Rossum wrote: > I still find this unfriendly to users of Python scripts and small apps who > are not the developers of those scripts. At a distro level, these warnings being off by default has actually turned out to be a problem, as it's precisely those user

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

06.11.17 09:09, Guido van Rossum пише: I still find this unfriendly to users of Python scripts and small apps who are not the developers of those scripts. (Large apps tend to spit out so much logging it doesn't really matter.) Isn't there a better heuristic we can come up with so that the warn

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

I still find this unfriendly to users of Python scripts and small apps who are not the developers of those scripts. (Large apps tend to spit out so much logging it doesn't really matter.) Isn't there a better heuristic we can come up with so that the warnings tend to be on for developers but off f

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

06.11.17 04:05, Nick Coghlan пише: On the 12-weeks-to-3.7-feature-freeze thread, Jose Bueno & I both mistakenly though the async/await deprecation warnings were missing from 3.6. They weren't missing, we'd just both forgotten those warnings were off by default (7 years after the change to the de

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

On 6 November 2017 at 16:26, Stephen J. Turnbull wrote: > Nick Coghlan writes: > > > Hence the proposed documentation change: the responsibility for > > silencing these warnings (for both their own code and for their > > dependencies) should rest with *application* developers, > > How do you pr

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

Nick Coghlan writes: > Hence the proposed documentation change: the responsibility for > silencing these warnings (for both their own code and for their > dependencies) should rest with *application* developers, How do you propose to handle users with legacy apps that they can't or their organ

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

On 6 November 2017 at 14:14, Barry Warsaw wrote: > On Nov 5, 2017, at 18:05, Nick Coghlan wrote: > >> So my proposal is simple (and not really new): let's revert back to >> the way things were in 2.6 and earlier, with DeprecationWarning being >> visible by default > > +1 > >> As part of this thou

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

On Nov 5, 2017, at 18:05, Nick Coghlan wrote: > So my proposal is simple (and not really new): let's revert back to > the way things were in 2.6 and earlier, with DeprecationWarning being > visible by default +1 > As part of this though, I'd suggest amending the documentation for > DeprecationW

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

On 6 November 2017 at 13:05, Nick Coghlan wrote: > As part of this though, I'd suggest amending the documentation for > DeprecationWarning [1] to specifically cover how to turn it off > programmatically (`warnings.simplefilter("ignore", > DeprecationWarning)`), at the command line (`python -W > i

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

On 6 November 2017 at 12:29, Oleg Broytman wrote: > On Sun, Nov 05, 2017 at 09:20:12PM -0500, Yury Selivanov > wrote: >> Big +1 from me. The whole point of DeprecationWarnings is to be >> visible > >The whole point of DeprecationWarnings is to be visible to > developers while in reality the

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

> On 5 Nov, 2017, at 6:29 PM, Oleg Broytman wrote: > > On Sun, Nov 05, 2017 at 09:20:12PM -0500, Yury Selivanov > wrote: >> Big +1 from me. The whole point of DeprecationWarnings is to be >> visible > > The whole point of DeprecationWarnings is to be visible to > developers while in reality

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

On Sun, Nov 05, 2017 at 09:20:12PM -0500, Yury Selivanov wrote: > Big +1 from me. The whole point of DeprecationWarnings is to be > visible The whole point of DeprecationWarnings is to be visible to developers while in reality they will be visible to users -- and what the users would do with

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

Big +1 from me. The whole point of DeprecationWarnings is to be visible so that they are resolved faster. The current behaviour allows them to go unnoticed for the majority of Python users. Yury On Sun, Nov 5, 2017 at 9:05 PM, Nick Coghlan wrote: > On the 12-weeks-to-3.7-feature-freeze thread,

[Python-Dev] Proposal: go back to enabling DeprecationWarning by default

On the 12-weeks-to-3.7-feature-freeze thread, Jose Bueno & I both mistakenly though the async/await deprecation warnings were missing from 3.6. They weren't missing, we'd just both forgotten those warnings were off by default (7 years after the change to the default settings in 2.7 & 3.2). So my