[issue24294] DeprecationWarnings should be visible by default in the interactive REPL

Change by Serhiy Storchaka : -- resolution: -> fixed stage: test needed -> resolved status: pending -> closed versions: +Python 3.7 -Python 3.6 ___ Python tracker ___

[issue24294] DeprecationWarnings should be visible by default in the interactive REPL

Serhiy Storchaka added the comment: After implementing PEP 565, are there reasons to keep this issue open? -- status: open -> pending ___ Python tracker ___

[issue24294] DeprecationWarnings should be visible by default in the interactive REPL

Aaron Meurer added the comment: If it's of any interest to this discussion, for SymPy (for some time) we have used a custom subclass of DeprecationWarning that we enable by default https://github.com/sympy/sympy/blob/master/sympy/utilities/exceptions.py. I don't know if

[issue24294] DeprecationWarnings should be visible by default in the interactive REPL

Nick Coghlan added the comment: I don't think anybody consistently does proper resource management in the REPL, so the trade-offs involved there are quite different from those for deprecation warnings. Assuming PEP 565 gets accepted, we'll end up with once-per-session

[issue24294] DeprecationWarnings should be visible by default in the interactive REPL

STINNER Victor added the comment: If you consider that the REPL is designed for developers, I would also suggest to show ResourceWarning by default. I'm not sure of that since I like to write crappy code of REPL (and I hope that nobody logs my keyboard)! Example:

[issue24294] DeprecationWarnings should be visible by default in the interactive REPL

Nathaniel Smith added the comment: See also PEP 565. -- ___ Python tracker ___ ___

[issue24294] DeprecationWarnings should be visible by default in the interactive REPL

Changes by Aaron Meurer : -- nosy: +Aaron.Meurer ___ Python tracker ___ ___

[issue24294] DeprecationWarnings should be visible by default in the interactive REPL

Matthias Bussonnier added the comment: > @mbussonn - I don't see an updated non-tty-checking patch from you? Sorry for the delay, trying to get back on this. Please find attached a new patch that does not check whether is is a tty. Still struggling a bit with HG (looking fwd to migration to

[issue24294] DeprecationWarnings should be visible by default in the interactive REPL

Changes by STINNER Victor : -- nosy: +haypo ___ Python tracker ___ ___

[issue24294] DeprecationWarnings should be visible by default in the interactive REPL

Robert Collins added the comment: @mbussonn - I don't see an updated non-tty-checking patch from you? -- ___ Python tracker ___

[issue24294] DeprecationWarnings should be visible by default in the interactive REPL

Changes by John Mark Vandenberg : -- nosy: +jayvdb ___ Python tracker ___ ___

[issue24294] DeprecationWarnings should be visible by default in the interactive REPL

Ezio Melotti added the comment: > It would help if there were some official guidance on what these things > mean -- I can't find anything written down anywhere that even documents > what you just said about how CPython proper uses them, so I imagine > people have come up with all kinds of

[issue24294] DeprecationWarnings should be visible by default in the interactive REPL

Nick Coghlan added the comment: The only way for this change to *break* something is if: 1. They're turning warnings into errors, or are otherwise sensitive to a deprecation warning being emitted 2. They're running code programmatically by way of an interactive REPL path I think we're far

[issue24294] DeprecationWarnings should be visible by default in the interactive REPL

R. David Murray added the comment: Matthias: just print it and let the doctest pass. That's consistent with how unittest works (unless warnings have been turned into errors, in which case it should fail, but I don't think you have to do anything to make that happen). Nick: OK. It is true

[issue24294] DeprecationWarnings should be visible by default in the interactive REPL

Matthias Bussonnier added the comment: # unittest (Pending)DeprecationWarning are already enabled if no -W flags are given. # doctest We enable the DW in REPL only if originate from `__main__`, this seem to be painful to do in doctest, as each doctest execute in a module that have the

[issue24294] DeprecationWarnings should be visible by default in the interactive REPL

Matthias Bussonnier added the comment: ok, thanks. I'll remove the is tty ans push docs changes on a new patch. I'll see if I can figure out how to enable DW by default in unittest and doctest. Thanks ! -- ___ Python tracker

[issue24294] DeprecationWarnings should be visible by default in the interactive REPL

Nick Coghlan added the comment: As Robert suggests, I think it's OK to issue the deprecation warnings for code run via python script.py or cat script.py | python. Reverting to the current behaviour if folks actually want that would just be a matter of passing the file in directly, rather

[issue24294] DeprecationWarnings should be visible by default in the interactive REPL

R. David Murray added the comment: I'm not sure that is acceptable. Just changing it to a file could break an application's structure that is depending on being able to use stdin to run scripts. As one example, vim scripts can embed python code...now, what VIM does behind the scenes with

[issue24294] DeprecationWarnings should be visible by default in the interactive REPL

Robert Collins added the comment: Hi, just to say - I'm happy to help steer this through. I think its an important ecosystem fixup. -- nosy: +rbcollins ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24294

[issue24294] DeprecationWarnings should be visible by default in the interactive REPL

Robert Collins added the comment: On testing this - I don't think subprocess tests are necessarily needed. The scenarios are these (from Nick's comment): Test frameworks. - there are two in the standard library. unittest and doctest. - unittest's code paths end up going through 'TestProgram'.

[issue24294] DeprecationWarnings should be visible by default in the interactive REPL

Nathaniel Smith added the comment: I don't see how any of those suggestions help for writing an automated test. Spawning a shell is irrelevant; the problem is to get a tty, which is much harder. There only way I can see that might work for an automated test is to use

[issue24294] DeprecationWarnings should be visible by default in the interactive REPL

Matthias Bussonnier added the comment: Would `pty` even work on CI where the terminal itself might not be a TTY ? subprocess.Popen(['bash', '-c', '''./python.exe -c import sys; print(sys.stdin.isatty())'''], stdin=subprocess.PIPE, stderr=subprocess.STDOUT) False Otherwise, I can

[issue24294] DeprecationWarnings should be visible by default in the interactive REPL

Nathaniel Smith added the comment: If pty is going to work at all then it should work regardless of whether the tests themselves are being run under a tty, yes. I personally would not want to merge a test based on making isatty lie, because the point of tests is to increase confidence that

[issue24294] DeprecationWarnings should be visible by default in the interactive REPL

Matthias Bussonnier added the comment: Astonishingly isatty appear to work on windows: http://bugs.python.org/issue18553 Up to core python for istty(). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24294

[issue24294] DeprecationWarnings should be visible by default in the interactive REPL

Jim Jewett added the comment: On windows, when python is started from the command line without a GUI, os.isatty(sys.stdin) raises an error, but os.isatty(sys.stdin.fileno()) returns true. Within IDLE, os.isatty(sys.stdin.fileno()) also raises an error, but os.isatty(0), os.isatty(1), and

[issue24294] DeprecationWarnings should be visible by default in the interactive REPL

Matthias Bussonnier added the comment: Hum, working on the automated test. It is slightly annoying as with subprocess python is not in a tty, so there will be no change in behavior. I'm not sure how to proceed. At a minimum, an interactive test should be written and added to the

[issue24294] DeprecationWarnings should be visible by default in the interactive REPL

Jim Jewett added the comment: Instead of using python directly in a subprocess, try calling a shell command that in turns calls python. (Admittedly, this may look like the pipe scenario...) In theory, you could even drive another python interactively, using a GUI runner, but I'm not sure

[issue24294] DeprecationWarnings should be visible by default in the interactive REPL

Jim Jewett added the comment: I've changed the stage to test needed. At a minimum, an interactive test should be written and added to the documentation. Better would be an automated test (perhaps via subprocess). The documentation should also be updated; at a minimum, there should be a

[issue24294] DeprecationWarnings should be visible by default in the interactive REPL

Matthias Bussonnier added the comment: Note that I've signed the CLA, and it has been taken into account, as now I have a small star agains my name (if it was the limiting factor, we never know). -- ___ Python tracker rep...@bugs.python.org

[issue24294] DeprecationWarnings should be visible by default in the interactive REPL

Nathaniel Smith added the comment: Ping. I know this is pretty trivial and everyone's focused on 3.5-related stuff, but it would be nice to get this finalized soon b/c the sooner CPython commits to some standard behavior here, the sooner all the other (faster-moving) python REPLs will

[issue24294] DeprecationWarnings should be visible by default in the interactive REPL

Nathaniel Smith added the comment: For whatever it's worth as a non-core-developer, the patch looks good to me. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24294 ___

[issue24294] DeprecationWarnings should be visible by default in the interactive REPL

Matthias Bussonnier added the comment: I gave that a shot. Doing it cleanly in C as the warning module is initialized much earlier. Though I'm not super used to CPython internals. Doing just before the repl by using `PyRun_SimpleString` make the patch relatively small. -- keywords:

[issue24294] DeprecationWarnings should be visible by default in the interactive REPL

Nathaniel Smith added the comment: Recording this here so it doesn't get lost: Marc-Andre Lemberg suggested on python-ideas that for the builtin REPL, this should be enabled iff sys.stdin.isatty(). (I guess he is worried about 'cat script.py | python'.) I'm not really sure whether this falls

[issue24294] DeprecationWarnings should be visible by default in the interactive REPL

Nathaniel Smith added the comment: There isn't really any magic in how warnings work. Basically someone calls warnings.warn(...), which is a regular Python function, and it gathers up some information about the specific warning message and calling context, checks a global variable

[issue24294] DeprecationWarnings should be visible by default in the interactive REPL

Terry J. Reedy added the comment: For Idle, the addition could be made in current versions. Idle compiles user code in the idle process and ships it to the user process for execution. In particular, idlelib.run.Executive.runcode, line 351, is exec(code, self.locals) Am I to

[issue24294] DeprecationWarnings should be visible by default in the interactive REPL

Nathaniel Smith added the comment: Okay, that sounds reasonable to me. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24294 ___ ___

[issue24294] DeprecationWarnings should be visible by default in the interactive REPL

Changes by Florian Bruhin python@the-compiler.org: -- nosy: +The Compiler ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24294 ___ ___

[issue24294] DeprecationWarnings should be visible by default in the interactive REPL

Martin Panter added the comment: I have learnt to run the interactive interpeter (and also most of my own scripts) with the -b -Wall options. But having these switched on automatically may not be a bad thing. -- nosy: +vadmium ___ Python tracker

[issue24294] DeprecationWarnings should be visible by default in the interactive REPL

Changes by Ezio Melotti ezio.melo...@gmail.com: -- nosy: +ezio.melotti ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24294 ___ ___

[issue24294] DeprecationWarnings should be visible by default in the interactive REPL

Serhiy Storchaka added the comment: See discussion on Python-Ideas [1]. [1] http://comments.gmane.org/gmane.comp.python.ideas/32191 -- components: +Interpreter Core nosy: +serhiy.storchaka versions: +Python 3.6 ___ Python tracker

[issue24294] DeprecationWarnings should be visible by default in the interactive REPL

Changes by Thomas Kluyver tak...@gmail.com: -- nosy: +takluyver ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24294 ___ ___ Python-bugs-list

[issue24294] DeprecationWarnings should be visible by default in the interactive REPL

Nathaniel Smith added the comment: *cough* You know, there's more to life than Python-X.Y.tar.gz :-). Not that I know how PendingDeprecationWarning is used in the wild. I've been thinking maybe we (numpy) should start using it for stuff that we want to discourage people from using (we know it

[issue24294] DeprecationWarnings should be visible by default in the interactive REPL

Nick Coghlan added the comment: The difference between the two used to be clearer: prior to Python 2.7, PendingDeprecationWarning was hidden by default (and thus mainly only visible to folks testing with -Wall), while DeprecationWarning was visible by default. We blurred the line between the

[issue24294] DeprecationWarnings should be visible by default in the interactive REPL

Nick Coghlan added the comment: +1 for showing DeprecationWarning by default (as these features may be going away in the next X.Y release of Python) -0 for showing PendingDeprecationWarning by default (as these won't be going away until X.Y+1 at the earliest) -- nosy: +ncoghlan

[issue24294] DeprecationWarnings should be visible by default in the interactive REPL

New submission from Nathaniel Smith: DeprecationWarning and PendingDeprecationWarning are invisible by default. The rationale for this is that they are only useful to people who are writing code, so they should not be shown to end-users who are merely running code. If someone is typing stuff

[issue24294] DeprecationWarnings should be visible by default in the interactive REPL

Nathaniel Smith added the comment: I also filed a similar bug with ipython: https://github.com/ipython/ipython/issues/8478 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24294 ___