Show deprecation warnings in the interactive interpreter
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.
Serhiy Storchaka <storchaka@gmail.com> writes:
What you are think about turning deprecation warnings on by default in the interactive interpreter?
In its favour: Exposing problems early, when they can easily be fixed, is good. To its detriment: Making the interactive interpreter behave differently by default from the non-interactive interpreter should be resisted; code which behaves a certain way by default in one should behave the same way in the other, without extremely compelling justification. I'm willing to hear more argument for and against. -- \ “Remember: every member of your ‘target audience’ also owns a | `\ broadcasting station. These ‘targets’ can shoot back.” —Michael | _o__) Rathbun to advertisers, news.admin.net-abuse.email | Ben Finney
On Wed, Feb 25, 2015 at 07:39:50PM +1100, Ben Finney wrote:
Serhiy Storchaka <storchaka@gmail.com> writes:
What you are think about turning deprecation warnings on by default in the interactive interpreter?
In its favour: Exposing problems early, when they can easily be fixed, is good.
To its detriment: Making the interactive interpreter behave differently by default from the non-interactive interpreter should be resisted; code which behaves a certain way by default in one should behave the same way in the other, without extremely compelling justification.
The ship has sailed on that one. In the interactive interpreter: py> 23 # Evaluating bare objects prints them. 23 py> _ 23 py> But non-interactively: [steve@ando ~]$ python -c "23
_" Traceback (most recent call last): File "<string>", line 2, in <module> NameError: name '_' is not defined
I think there are three questions that should be asked: (1) How does one easy and simply enable warnings in the interactive interpeter? (2) If they are enabled by default, how does one easily and simply disable the again? E.g. from the command line itself, or from your PYTHONSTARTUP file. (3) Should they be enabled? I can't give an opinion on (3) until I know the answer to (1) and (2). I tried looking at the warnings module and the sys module but nothing stands out to me. -- Steve
Steven D'Aprano <steve@pearwood.info> writes:
On Wed, Feb 25, 2015 at 07:39:50PM +1100, Ben Finney wrote:
To its detriment: Making the interactive interpreter behave differently by default from the non-interactive interpreter should be resisted; code which behaves a certain way by default in one should behave the same way in the other, without extremely compelling justification.
The ship has sailed on that one. […]
Please note two things: I don't claim there must be no differences, only that differences proposed today must come with compellign justification. The fact that there are already differences doesn't justify diverging further. Whatever positive justification is offered, “they already diverge” cannot count for creating further divergence. -- \ “I have the simplest tastes. I am always satisfied with the | `\ best.” —Oscar Wilde | _o__) | Ben Finney
On Wed, Feb 25, 2015 at 9:01 PM, Ben Finney <ben+python@benfinney.id.au> wrote:
Steven D'Aprano <steve@pearwood.info> writes:
On Wed, Feb 25, 2015 at 07:39:50PM +1100, Ben Finney wrote:
To its detriment: Making the interactive interpreter behave differently by default from the non-interactive interpreter should be resisted; code which behaves a certain way by default in one should behave the same way in the other, without extremely compelling justification.
The ship has sailed on that one. […]
Please note two things:
I don't claim there must be no differences, only that differences proposed today must come with compellign justification.
The fact that there are already differences doesn't justify diverging further. Whatever positive justification is offered, “they already diverge” cannot count for creating further divergence.
Agreed; the difference does need justification. Here's justification: Interactive execution places code and output right next to each other. The warning would be emitted right at the time when the corresponding code is entered. Hmm. There are a few places where code gets pre-evaluated by the back end (eg to figure out whether a continuation prompt is needed). Should applicable SyntaxWarnings be emitted during such partial evaluation, or should they be held over until the whole block can be parsed? ChrisA
On 25 February 2015 at 10:17, Chris Angelico <rosuav@gmail.com> wrote:
Agreed; the difference does need justification. Here's justification: Interactive execution places code and output right next to each other. The warning would be emitted right at the time when the corresponding code is entered.
On the other hand, what if "import <3rd party module>" flags a deprecation warning because of something the module author does? Certainly I can just ignore it (as it's "only" a warning) but it would get annoying pretty fast if I couldn't suppress it... Paul
On Wed, Feb 25, 2015 at 9:21 PM, Paul Moore <p.f.moore@gmail.com> wrote:
On 25 February 2015 at 10:17, Chris Angelico <rosuav@gmail.com> wrote:
Agreed; the difference does need justification. Here's justification: Interactive execution places code and output right next to each other. The warning would be emitted right at the time when the corresponding code is entered.
On the other hand, what if "import <3rd party module>" flags a deprecation warning because of something the module author does? Certainly I can just ignore it (as it's "only" a warning) but it would get annoying pretty fast if I couldn't suppress it...
That might be a good excuse to lean on the module's author or submit a patch. :) But yes, that does present a problem, especially since warnings will, by default, show only once (if I'm understanding the docs correctly) - you ignore it in the import, and it's suppressed for the rest of the session. ChrisA
On 25 February 2015 at 10:35, Chris Angelico <rosuav@gmail.com> wrote:
On the other hand, what if "import <3rd party module>" flags a deprecation warning because of something the module author does? Certainly I can just ignore it (as it's "only" a warning) but it would get annoying pretty fast if I couldn't suppress it...
That might be a good excuse to lean on the module's author or submit a patch. :) But yes, that does present a problem, especially since warnings will, by default, show only once (if I'm understanding the docs correctly) - you ignore it in the import, and it's suppressed for the rest of the session.
The important point here is that the idea behind this proposal is that enabling deprecation warnings in the REPL is viable because the warnings will be referring to your code, and therefore you can choose whether or not to deal with them there and then. But 3rd party modules are a case where that isn't the case. Deprecation warnings were hidden by default in the first place because the people who were affected by them were typically not the people who controlled the code triggering them. I don't think just showing them in the REPL alters that much. Maybe the right solution is for testing frameworks (unittest, nose, py.test) to force deprecation warnings on. Then developers will be told about deprecation issues when they run their tests. Paul
On 25 February 2015 at 20:58, Paul Moore <p.f.moore@gmail.com> wrote:
Maybe the right solution is for testing frameworks (unittest, nose, py.test) to force deprecation warnings on. Then developers will be told about deprecation issues when they run their tests.
This is already done. The environments that still hit issues these days are thus those afflicted with untested code, like system administrator's utility scripts, data analysis and applications without(!) automated regression tests. I still think it was the right call to make, but it was not without its negative consequences :( Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Feb 25, 2015 2:58 AM, "Paul Moore" <p.f.moore@gmail.com> wrote:
On 25 February 2015 at 10:35, Chris Angelico <rosuav@gmail.com> wrote:
On the other hand, what if "import <3rd party module>" flags a deprecation warning because of something the module author does? Certainly I can just ignore it (as it's "only" a warning) but it would get annoying pretty fast if I couldn't suppress it...
That might be a good excuse to lean on the module's author or submit a patch. :) But yes, that does present a problem, especially since warnings will, by default, show only once (if I'm understanding the docs correctly) - you ignore it in the import, and it's suppressed for the rest of the session.
The important point here is that the idea behind this proposal is that enabling deprecation warnings in the REPL is viable because the warnings will be referring to your code, and therefore you can choose whether or not to deal with them there and then. But 3rd party modules are a case where that isn't the case.
Warnings have both a type (DeprecationWarning) and a source (line 37 of module X), with the idea being that the source is supposed to point to the code that's doing something questionable (which generally isn't the code that called warnings.warn). It would be totally possible to enable display of only those DeprecationWarnings that are attributed to stuff typed in at the REPL. And it sounds like a great idea to me. (NB that if we do this we'll run into another annoying problem with warnings and the REPL, which is that every line typed in the REPL is "line 1", so generally any given warning will only be produced once even if the offending behavior occurs in multiple different statements. This tends to really confuse users, since it means you can't use trial and error to figure out what was wrong with your code: whatever tweak you try first will always appear to fix the problem. Some more discussion of this issue here: https://github.com/ipython/ipython/pull/6680) -n
On 25.02.15 19:49, Nathaniel Smith wrote:
(NB that if we do this we'll run into another annoying problem with warnings and the REPL, which is that every line typed in the REPL is "line 1", so generally any given warning will only be produced once even if the offending behavior occurs in multiple different statements. This tends to really confuse users, since it means you can't use trial and error to figure out what was wrong with your code: whatever tweak you try first will always appear to fix the problem. Some more discussion of this issue here: https://github.com/ipython/ipython/pull/6680)
Every REPL input can be considered as different source.
On Feb 25, 2015 11:23 AM, "Serhiy Storchaka" <storchaka@gmail.com> wrote:
On 25.02.15 19:49, Nathaniel Smith wrote:
(NB that if we do this we'll run into another annoying problem with warnings and the REPL, which is that every line typed in the REPL is "line 1", so generally any given warning will only be produced once even if the offending behavior occurs in multiple different statements. This tends to really confuse users, since it means you can't use trial and error to figure out what was wrong with your code: whatever tweak you try first will always appear to fix the problem. Some more discussion of this issue here: https://github.com/ipython/ipython/pull/6680)
Every REPL input can be considered as different source.
Well, yes, and they ought to be considered different sources. My point is just that at the moment they aren't considered different sources, so if we're worrying about doing better warning reporting from the REPL then we might want to think about this too, since it will limit the effectiveness of other efforts. -n
On 26 February 2015 at 05:58, Nathaniel Smith <njs@pobox.com> wrote:
On Feb 25, 2015 11:23 AM, "Serhiy Storchaka" <storchaka@gmail.com> wrote:
On 25.02.15 19:49, Nathaniel Smith wrote:
(NB that if we do this we'll run into another annoying problem with warnings and the REPL, which is that every line typed in the REPL is "line 1", so generally any given warning will only be produced once even if the offending behavior occurs in multiple different statements. This tends to really confuse users, since it means you can't use trial and error to figure out what was wrong with your code: whatever tweak you try first will always appear to fix the problem. Some more discussion of this issue here: https://github.com/ipython/ipython/pull/6680)
Every REPL input can be considered as different source.
Well, yes, and they ought to be considered different sources. My point is just that at the moment they aren't considered different sources, so if we're worrying about doing better warning reporting from the REPL then we might want to think about this too, since it will limit the effectiveness of other efforts.
Setting the action to "always" and filtering on the main module should do the trick:
import warnings warnings.filterwarnings("always", module="__main__") warnings.warn("Deprecated", DeprecationWarning) __main__:1: DeprecationWarning: Deprecated
Injecting that into the list of default filters when starting the interactive interpreter also isn't too difficult, so it would be pretty straightforward to get the interpreter to do this implicitly: $ python3 '-Walways:::__main__' Python 3.4.1 (default, Nov 3 2014, 14:38:10) [GCC 4.9.1 20140930 (Red Hat 4.9.1-11)] on linux Type "help", "copyright", "credits" or "license" for more information.
import warnings warnings.warn("Deprecated", DeprecationWarning) __main__:1: DeprecationWarning: Deprecated
It may also be worthwhile introducing a "-Wmain" shorthand for "-Wdefault:::__main__", as I could see that being quite useful to system administrators, data analysts, et al, that want to know about deprecation warnings in their own custom scripts, but don't really care about deprecations in support libraries. Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Thu, 26 Feb 2015 07:35:17 +1000 Nick Coghlan <ncoghlan@gmail.com> wrote:
It may also be worthwhile introducing a "-Wmain" shorthand for "-Wdefault:::__main__", as I could see that being quite useful to system administrators, data analysts, et al, that want to know about deprecation warnings in their own custom scripts, but don't really care about deprecations in support libraries.
-1. This is making the "main script" special while code factored out in another module won't benefit. Furthermore there hasn't been any demand for this. Regards Antoine.
On 26 February 2015 at 08:03, Antoine Pitrou <solipsis@pitrou.net> wrote:
On Thu, 26 Feb 2015 07:35:17 +1000 Nick Coghlan <ncoghlan@gmail.com> wrote:
It may also be worthwhile introducing a "-Wmain" shorthand for "-Wdefault:::__main__", as I could see that being quite useful to system administrators, data analysts, et al, that want to know about deprecation warnings in their own custom scripts, but don't really care about deprecations in support libraries.
-1. This is making the "main script" special while code factored out in another module won't benefit. Furthermore there hasn't been any demand for this.
Yes there has, at the Linux distro level. I just haven't escalated it upstream because I didn't think there was anything useful we could do about it given the previous decision to default to silencing deprecation warnings by default outside testing frameworks. The key problem with the status quo from my perspective is that sysadmins currently don't get any warning that their scripts might have problems when Fedora next upgrades to a new version of Python, because they're not getting the deprecation warnings by default. Given a -Wmain option upstream, I'd likely try to make the case for that as the default behaviour of the distro system Python, but without "enable all warnings for __main__" at least being a readily available behaviour in the reference interpreter, it's arguably too much of a divergence (since we'd be defining the new behaviour ourselves, rather than selecting a different upstream behaviour as the default) Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Thu, 26 Feb 2015 08:34:31 +1000 Nick Coghlan <ncoghlan@gmail.com> wrote:
The key problem with the status quo from my perspective is that sysadmins currently don't get any warning that their scripts might have problems when Fedora next upgrades to a new version of Python, because they're not getting the deprecation warnings by default.
The focus on sysadmins sounds a bit gratuitous here. Furthermore I don't see why sysadmins would only use "main scripts" and not factor out their code. Besides, we don't want to add an option which would *discourage* factoring out code. Another reason why this may be counter-productive: if you run your script through a stub, then the warnings disappear again. And this is adding a new variant to the '-W' option, which is already complicated to learn. The real issue is that we silenced deprecation warnings at all. There's nothing specific about "main scripts": every module suffers. Regards Antoine.
On Thu, Feb 26, 2015 at 9:44 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:
The focus on sysadmins sounds a bit gratuitous here. Furthermore I don't see why sysadmins would only use "main scripts" and not factor out their code. Besides, we don't want to add an option which would *discourage* factoring out code.
Another reason why this may be counter-productive: if you run your script through a stub, then the warnings disappear again.
If drawing the line at __main__ is a problem, is it possible to enable warnings for "everything that came from the first entry in sys.path"? Or, if it helps, disable warnings for a specific set of paths? That way, you could factor out code into a local module (imported from the main module's directory) and still have warnings, but not have them for the stuff that you consider to be library modules. ChrisA
On Wed, 25 Feb 2015 14:49:42 -0800 Ethan Furman <ethan@stoneleaf.us> wrote:
On 02/25/2015 02:44 PM, Antoine Pitrou wrote:
There's nothing specific about "main scripts": every module suffers.
There may be nothing special about "main scripts", but there is something special about __main__: it's where hand-entered code runs when using the REPL.
Then let's make the REPL enable those warnings rather than entertain new command-line arguments. Regards Antoine.
On 2/25/2015 4:35 PM, Nick Coghlan wrote:
Setting the action to "always" and filtering on the main module should do the trick:
import warnings warnings.filterwarnings("always", module="__main__")
Changing interactive-mode python is irrelevant to gui environments running on batch-mode python, except for adding another requirement for simulating interactive python and its command prompt. Idle starts idlelib/PyShell.py in one process (the Idle process) and (in default mode) idlelib/run.py in a second process (the User process) and makes a bidirectional connection. The Idle process compiles user code with compile(codestring, ...) and sends the code object to the User process, which executes it with exec(usercode, namespace). Both processes already import warnings. If I add the line above to run.py, I get
warnings.warn("Deprecated", DeprecationWarning)
Warning (from warnings module): File "__main__", line 1 DeprecationWarning: Deprecated (on stderr) instead of nothing. I presume this should be sufficient for runtime warnings, but are there any raised during compilation (like SyntaxWarnings, or Py3kWarnings in 2.7)? I see nothing in the compile() doc about turning warnings on or off. -- Terry Jan Reedy
On 25 February 2015 at 20:21, Paul Moore <p.f.moore@gmail.com> wrote:
On 25 February 2015 at 10:17, Chris Angelico <rosuav@gmail.com> wrote:
Agreed; the difference does need justification. Here's justification: Interactive execution places code and output right next to each other. The warning would be emitted right at the time when the corresponding code is entered.
On the other hand, what if "import <3rd party module>" flags a deprecation warning because of something the module author does? Certainly I can just ignore it (as it's "only" a warning) but it would get annoying pretty fast if I couldn't suppress it...
Ah, this is exactly the reason we turned them off in the first place (only applied at the module level, rather than the whole application level). That puts me firmly in the -1 camp, for the same reason we turned them off in the first place. Turning them all on is a matter of passing "-Wall" at the command line, but the command line help could stand to say that explicitly (currently it only describes the full selective warning control syntax, without mentioning the "all", "once" and "error" shorthands: https://docs.python.org/3/using/cmdline.html#cmdoption-W) Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On 25 February 2015 at 09:55, Steven D'Aprano <steve@pearwood.info> wrote:
I think there are three questions that should be asked:
(1) How does one easy and simply enable warnings in the interactive interpeter?
(2) If they are enabled by default, how does one easily and simply disable the again? E.g. from the command line itself, or from your PYTHONSTARTUP file.
(3) Should they be enabled?
I can't give an opinion on (3) until I know the answer to (1) and (2). I tried looking at the warnings module and the sys module but nothing stands out to me.
Agreed. Also, what about 3rd party REPLs like IPython? Will they be affected by the change, and will the enabling/disabling mechanism work for them? (e.g. I don't think IPython checks PYTHONSTARTUP). Another question which should probably be answered, how many deprecation warnings are / would be active when this change is made? One of the reasons for the change is clearly that deprecation warnings aren't very easy to see at the moment, but that does mean it's difficult to assess the impact of this change. Paul
On 25.02.15 11:55, Steven D'Aprano wrote:
I think there are three questions that should be asked:
(1) How does one easy and simply enable warnings in the interactive interpeter?
Same as for other warnings. import warnings; warnings.simplefilter('once', DeprecationWarning) Or 'module', 'always', 'error'.
(2) If they are enabled by default, how does one easily and simply disable the again? E.g. from the command line itself, or from your PYTHONSTARTUP file.
Same as for other warnings. import warnings; warnings.simplefilter('ignore', DeprecationWarning)
On 2/25/2015 3:39 AM, Ben Finney wrote:
Serhiy Storchaka <storchaka@gmail.com> writes:
What you are think about turning deprecation warnings on by default in the interactive interpreter?
I don't really get the point. It seems to me that the idea is to have warnings optionally on during development, always off during production. Most development, especially of 'permanent' code, does not take place at the interactive prompt.
In its favour: Exposing problems early, when they can easily be fixed, is good.
I think the idea of turning warnings on and off would better work as an Idle option for the user process that executes user code. The option would take effect the next time the user process is restarted, which is every time code is run from the editor, or when selected by the user.
To its detriment: Making the interactive interpreter behave differently by default from the non-interactive interpreter should be resisted; code which behaves a certain way by default in one should behave the same way in the other, without extremely compelling justification.
An Idle option would apply to both code run from the editor and code entered at the Shell prompt. Other IDEs could do the same. I presume Warnings are issued on stderr. If so, Idle would give them the stderr color, making them less confused with the differently colored program stdout output. -- Terry Jan Reedy
On Wed, Feb 25, 2015 at 1:45 PM, Terry Reedy <tjreedy@udel.edu> wrote:
On 2/25/2015 3:39 AM, Ben Finney wrote:
Serhiy Storchaka <storchaka@gmail.com> writes:
What you are think about turning deprecation warnings on by default in the interactive interpreter?
I don't really get the point. It seems to me that the idea is to have warnings optionally on during development, always off during production. Most development, especially of 'permanent' code, does not take place at the interactive prompt.
This reasoning seems backwards to me. It doesn't matter whether there is also code being developed non-interactively; the question is, for that code which *is* developed interactively, should warnings be visible by default. BTW, the people around me seem to be developing possibly a majority of their code these days by starting out iteratively refining stuff using the ipython notebook as a REPL. -- Nathaniel J. Smith -- http://vorpus.org
On 2/25/2015 5:04 PM, Nathaniel Smith wrote:
On Wed, Feb 25, 2015 at 1:45 PM, Terry Reedy <tjreedy@udel.edu> wrote:
On 2/25/2015 3:39 AM, Ben Finney wrote:
Serhiy Storchaka <storchaka@gmail.com> writes:
What you are think about turning deprecation warnings on by default in the interactive interpreter?
I don't really get the point. It seems to me that the idea is to have warnings optionally on during development, always off during production. Most development, especially of 'permanent' code, does not take place at the interactive prompt.
This reasoning seems backwards to me. It doesn't matter whether there is also code being developed non-interactively; the question is, for that code which *is* developed interactively, should warnings be visible by default.
I develop interactively by editing a bit, running, ......, with occasional use of the Idle prompt after running.
BTW, the people around me seem to be developing possibly a majority of their code these days by starting out iteratively refining stuff using the ipython notebook as a REPL.
You comment actually supports the more important part of my post, which you snipped. An ipython notebook, like Idle, is not the interactive interpreter. It would have to be changed independently, as would Idle. Neither has to wait for an 'official' change. Idle would not be changed by a change only to the official interactive interpreter. I suspect that the same would also be true of ipython, but I am not familiar with its implementation as to how it actually runs code entered by users. -- Terry Jan Reedy
On Wed, Feb 25, 2015, at 16:45, Terry Reedy wrote:
On 2/25/2015 3:39 AM, Ben Finney wrote:
Serhiy Storchaka <storchaka@gmail.com> writes:
What you are think about turning deprecation warnings on by default in the interactive interpreter?
I don't really get the point. It seems to me that the idea is to have warnings optionally on during development, always off during production. Most development, especially of 'permanent' code, does not take place at the interactive prompt.
I think the idea is that people experiment at the interactive prompt and warnings will help them learn good habits.
On 2/25/2015 6:27 PM, random832@fastmail.us wrote:
On Wed, Feb 25, 2015, at 16:45, Terry Reedy wrote:
On 2/25/2015 3:39 AM, Ben Finney wrote:
Serhiy Storchaka <storchaka@gmail.com> writes:
What you are think about turning deprecation warnings on by default in the interactive interpreter?
I don't really get the point. It seems to me that the idea is to have warnings optionally on during development, always off during production. Most development, especially of 'permanent' code, does not take place at the interactive prompt.
I think the idea is that people experiment at the interactive prompt and warnings will help them learn good habits.
People often experiment with files in editors when writing statements longer than a line or two or when writing multiple statements. Leaving that aside, people also experiment at *simulated* interactive prompts in guis, such as Idle, that run on Python in normal batch mode. In either case, changing interactive mode python will have no effect and no benefit. -- Terry Jan Reedy
On Wed, Feb 25, 2015, at 19:47, Terry Reedy wrote:
People often experiment with files in editors when writing statements longer than a line or two or when writing multiple statements. Leaving that aside, people also experiment at *simulated* interactive prompts in guis, such as Idle, that run on Python in normal batch mode. In either case, changing interactive mode python will have no effect and no benefit.
Well obviously another change would have to be made to Idle. Your argument seems to boil down to "no-one uses the prompt", so why not just get rid of it?
On 26 February 2015 at 16:15, <random832@fastmail.us> wrote:
On Wed, Feb 25, 2015, at 19:47, Terry Reedy wrote:
People often experiment with files in editors when writing statements longer than a line or two or when writing multiple statements. Leaving that aside, people also experiment at *simulated* interactive prompts in guis, such as Idle, that run on Python in normal batch mode. In either case, changing interactive mode python will have no effect and no benefit.
Well obviously another change would have to be made to Idle.
Your argument seems to boil down to "no-one uses the prompt", so why not just get rid of it?
I use the prompt pretty much all the time (and yes, that's on Windows - I imagine a lot of Unix users use the prompt :-)) Paul
On Feb 26, 2015 9:33 AM, "Terry Reedy" <tjreedy@udel.edu> wrote:
On 2/26/2015 11:15 AM, random832@fastmail.us wrote:
Your argument seems to boil down to "no-one uses the prompt", so why not just get rid of it?
Mangling what people write beyond recognition does not help improve
python. I understand it's frustrating when people write snarky one liners picking on you, but having read all your comments here (and having tried and then given up on replying to your last reply to me): if this is not an accurate summary of what you're trying to argue, then I honestly have no idea what you are trying to argue. -n
Nathaniel Smith writes:
On Feb 26, 2015 9:33 AM, "Terry Reedy" <tjreedy@udel.edu> wrote:
On 2/26/2015 11:15 AM, random832@fastmail.us wrote:
Your argument seems to boil down to "no-one uses the prompt", so why not just get rid of it?
[Hardly.]
[I]f this is not an accurate summary of what you're trying to argue, then I honestly have no idea what you are trying to argue.
I'm surprised at "no idea". He's been clear throughout that because there are *many* alternative interactive interfaces besides the CPython interpreter itself, to be truly effective the warnings need to be propagated to those, and it's not automatic because most of them don't use the interactive interpreter. IIUC, at least in IDLE it's already possible to get them with some fiddling. Since it's debatable how important this is to interactive prompt users (especially those on POSIX systems), he thinks that to be effective it requires much more to change than just the CPython interpreter, and since it may annoy more users than would be helped, he doesn't seem to think the change is justified. I think personally I tend toward the side that the proposed warning display is a good idea even if of limited benefit, it's not likely to bother too many users, and it can be extended as desired to the alternative interactive UIs. But that doesn't mean I don't understand his point of view.
On Feb 26, 2015 6:20 PM, "Stephen J. Turnbull" <stephen@xemacs.org> wrote:
Nathaniel Smith writes:
On Feb 26, 2015 9:33 AM, "Terry Reedy" <tjreedy@udel.edu> wrote:
On 2/26/2015 11:15 AM, random832@fastmail.us wrote:
Your argument seems to boil down to "no-one uses the prompt", so
why not
just get rid of it?
[Hardly.]
[I]f this is not an accurate summary of what you're trying to argue, then I honestly have no idea what you are trying to argue.
I'm surprised at "no idea". He's been clear throughout that because there are *many* alternative interactive interfaces besides the CPython interpreter itself, to be truly effective the warnings need to be propagated to those, and it's not automatic because most of them don't use the interactive interpreter. IIUC, at least in IDLE it's already possible to get them with some fiddling. Since it's debatable how important this is to interactive prompt users (especially those on POSIX systems), he thinks that to be effective it requires much more to change than just the CPython interpreter, and
Right, I think everyone can agree with all that.
since it may annoy more users than would be helped, he doesn't seem to think the change is justified.
... But afaict Terry has not said one word of this; either I'm missing something or you're doing the same thing as random832 and filling in the gaps with guesses. Which is totally reasonable, natural language understanding always requires filling in gaps like this, and I'm not annoyed at anyone or anything (maybe my last message came across as somewhat hostile? My apologies if so). Really I just think Terry should realize that they haven't been as clear as they think and elaborate, because I actually would like to know what they're saying. -n
On 2/26/2015 9:43 PM, Nathaniel Smith wrote:
On Feb 26, 2015 6:20 PM, "Stephen J. Turnbull"
Nathaniel Smith writes:
I honestly have no idea what [Terry is] trying to argue.
I'm surprised at "no idea". He's been clear throughout that because there are *many* alternative interactive interfaces besides the CPython interpreter itself, to be truly effective the warnings need to be propagated to those, and it's not automatic because most of them don't use the interactive interpreter.
Nice summary, Stephen. Thanks. Add the fact that interactive development takes place in editable text as well as at a '>>> ' prompt. In Idle, adding a new statement to the current session at '>>> ' and hitting return and adding a new statement to a current file and hitting F5 are similar actions. (And they are handled nearly the same by Idle.) There are pluses and minuses both ways and I use both, ofter interleaved. I also noted that I occasionally use the real interactive interpreter to work on Idle. Guido said that it is OK to help some but not all, and that he would leave it to IDE maintainers to extend the idea. Using Nick's hints, I worked out two ways to apply the idea to Idle, one trivial, one not. The trivial fix would apply to all code, whether submitted by '\n' or F5. The other fix could apply to both, probably more easily than not.
Right, I think everyone can agree with all that.
since it may annoy more users than would be helped, he doesn't seem to think the change is justified.
... But afaict Terry has not said one word of this;
Nathanial, you are right here. I like to understand the practical implications of an idea like this before making a strong judgement. -- Terry Jan Reedy
On 2/25/2015 4:28 PM, Ethan Furman wrote:
On 02/24/2015 11:51 PM, Serhiy Storchaka wrote:
What you are think about turning deprecation warnings on by default in the interactive interpreter?
-1
One can use the commandline switch if one wants to.
A change limited to the interactive interpreter would be meaningless for everyone who works at a simulated prompt in a gui program running on non-interactive python, or running user code under supervision in non-interactive python. This includes both modes of Idle (default and -n). I presume this includes nearly any other alternative to the console interpreter. On Windows, the actual Command Prompt interactive interpreter is a wretched environment. I only use it to start Idle on repository builds and to check whether Idle does the same thing as the console interpreter. I suspect that many users on Windows never see the console interpreter, just as they many never see a command prompt command line. -- Terry Jan Reedy
Well, you can turn warnings or off using a command line flag or by making calls into the warnings module, so everyone who emulates a REPL can copy this behavior. I'm not worried about that. On Wed, Feb 25, 2015 at 4:20 PM, Terry Reedy <tjreedy@udel.edu> wrote:
On 2/25/2015 4:28 PM, Ethan Furman wrote:
On 02/24/2015 11:51 PM, Serhiy Storchaka wrote:
What you are think about turning deprecation warnings on by default
in the interactive interpreter?
-1
One can use the commandline switch if one wants to.
A change limited to the interactive interpreter would be meaningless for everyone who works at a simulated prompt in a gui program running on non-interactive python, or running user code under supervision in non-interactive python. This includes both modes of Idle (default and -n). I presume this includes nearly any other alternative to the console interpreter.
On Windows, the actual Command Prompt interactive interpreter is a wretched environment. I only use it to start Idle on repository builds and to check whether Idle does the same thing as the console interpreter. I suspect that many users on Windows never see the console interpreter, just as they many never see a command prompt command line.
-- Terry Jan Reedy
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
-- --Guido van Rossum (python.org/~guido)
On 2/25/2015 7:45 PM, Guido van Rossum wrote:
Well, you can turn warnings or off using a command line flag or by making calls into the warnings module, so everyone who emulates a REPL can copy this behavior. I'm not worried about that.
See my later response to Nick. After adding the one line to my installed 3.4.3 idlelib/run.py, the runtime DeprecationWarning raised by from ftplib import Netrc; Netrc() is displayed, whether the above is entered in the Shell or run from the editor. I would not mind adding the one line to run.py (for all current versions) and being done with it. Idle is mostly intended for development. Making the warning display optional would be far, far harder. As I said previously, I do not know for sure if there are compile-time DeprecationWarnings to try to deal with. -- Terry Jan Reedy
On 2/25/2015 9:38 PM, Terry Reedy wrote:
On 2/25/2015 7:45 PM, Guido van Rossum wrote:
Well, you can turn warnings or off using a command line flag or by making calls into the warnings module, so everyone who emulates a REPL can copy this behavior. I'm not worried about that.
I just discovered that Idle uses sys.warnoptions when starting a subprocess, so users can get all warnings now if they want, or pass Nick's suggested '-Wdefault:::__main__' for main code only.
See my later response to Nick. After adding the one line to my installed 3.4.3 idlelib/run.py, the runtime DeprecationWarning raised by from ftplib import Netrc; Netrc() is displayed, whether the above is entered in the Shell or run from the editor. I would not mind adding the one line to run.py (for all current versions) and being done with it. Idle is mostly intended for development.
Making the warning display optional would be far, far harder.
Make that just 'somewhat harder'. Manipulating sys.warnoptions would affect the next restart. It would still be perhaps 30 new lines of code, and some decisions on details. -- Terry Jan Reedy
Hi, Python has more and more options to emit warnings or enable more checks. Maybe we need one global "strict" option to simply enable all checks and warnings at once? For example, there are deprecation warnings, but also resource warnings. Both should be enabled in the strict mode. Another example is the -bb command line option (bytes watning). It should also be enabled. More example: -tt (warnings on indentation). It can be a command line option, an environment variable and a function to enable it. Perl has "use strict;". For the interactive interpreter, the strict code may be enabled by default, but only if it's easy to disable it. Victor Le mercredi 25 février 2015, Serhiy Storchaka <storchaka@gmail.com> a écrit :
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@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
On Wed, Feb 25, 2015 at 5:40 PM Victor Stinner <victor.stinner@gmail.com> wrote:
Hi,
Python has more and more options to emit warnings or enable more checks. Maybe we need one global "strict" option to simply enable all checks and warnings at once?
For example, there are deprecation warnings, but also resource warnings. Both should be enabled in the strict mode. Another example is the -bb command line option (bytes watning). It should also be enabled. More example: -tt (warnings on indentation).
It can be a command line option, an environment variable and a function to enable it.
Perl has "use strict;".
For the interactive interpreter, the strict code may be enabled by default, but only if it's easy to disable it.
Regardless of this REPL discussions, having something like a --strict flag to switch on every single warning that you can switch on to its highest level would be handy to have. -Brett
Victor
Le mercredi 25 février 2015, Serhiy Storchaka <storchaka@gmail.com> a écrit :
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@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
On Thu, 26 Feb 2015 15:35:00 +0000 Brett Cannon <brett@python.org> wrote:
On Wed, Feb 25, 2015 at 5:40 PM Victor Stinner <victor.stinner@gmail.com> wrote:
Hi,
Python has more and more options to emit warnings or enable more checks. Maybe we need one global "strict" option to simply enable all checks and warnings at once?
For example, there are deprecation warnings, but also resource warnings. Both should be enabled in the strict mode. Another example is the -bb command line option (bytes watning). It should also be enabled. More example: -tt (warnings on indentation).
It can be a command line option, an environment variable and a function to enable it.
Perl has "use strict;".
For the interactive interpreter, the strict code may be enabled by default, but only if it's easy to disable it.
Regardless of this REPL discussions, having something like a --strict flag to switch on every single warning that you can switch on to its highest level would be handy to have.
Isn't that "-Walways" ? (IIRC) Regards Antoine.
Hi, On Wed, Feb 25, 2015 at 9:51 AM, Serhiy Storchaka <storchaka@gmail.com> wrote:
What you are think about turning deprecation warnings on by default in the interactive interpreter?
+1 If I'm using the interpreter to try some piece of code I'm not familiar with, I would rather get a warning immediately and proceed to find the right solution, rather than spending time figuring out how some deprecated function works, use it in my application, write the tests for it, and only then find out that I've been wasting my time with something that was deprecated (or worse, find it out once I update Python and the function is no longer there). Using flags (both existing and new proposed ones) to enable warnings has three issues: 1) you have to know that deprecation warnings are silenced by default and that there is an option to enable them; 2) you have to remember the flag/syntax to enable them; 3) you have to do it every time you start the interpreter; Realistically I don't see people starting using "python3 --some-flag" regularly just to see all the warnings. Regarding deprecation warnings raised while importing 3rd party code: 1) most of the time there's very little code executed at import time (mostly function/classes definitions), so the chance of getting warnings should be quite low; 2) if there are warnings (e.g. because the module I'm importing imports some deprecated module), I can either report them upstream or simply dismiss them. Seeing that there are warnings might also make me reconsider the use of the module (since it might not work on more recent Pythons, or might even have security implications). Best Regards, Ezio Melotti
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.
On Wed, Feb 25, 2015 at 8:51 AM, Serhiy Storchaka <storchaka@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@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. -- Giampaolo - http://grodola.blogspot.com
On 3 March 2015 at 10:46, Giampaolo Rodola' <g.rodola@gmail.com> wrote:
On Wed, Feb 25, 2015 at 8:51 AM, Serhiy Storchaka <storchaka@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@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@gmail.com | Brisbane, Australia
participants (17)
-
Antoine Pitrou -
Ben Finney -
Brett Cannon -
Chris Angelico -
Ethan Furman -
Ezio Melotti -
Giampaolo Rodola' -
Guido van Rossum -
Nathaniel Smith -
Nick Coghlan -
Paul Moore -
random832＠fastmail.us -
Serhiy Storchaka -
Stephen J. Turnbull -
Steven D'Aprano -
Terry Reedy -
Victor Stinner