classification
Title: parsetok.c emits warnings by writing to stderr
Type: enhancement Stage: resolved
Components: Interpreter Core Versions: Python 3.3
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: anthonybaxter, brett.cannon, eric.araujo, exarkun, ezio.melotti, jafo, kuran, maker, pablogsal, terry.reedy
Priority: normal Keywords:

Created on 2006-07-30 21:37 by kuran, last changed 2020-01-13 11:59 by pablogsal. This issue is now closed.

Messages (16)
msg60952 - (view) Author: Jp Calderone (kuran) Date: 2006-07-30 21:37
Warnings should be emitted with the warning system, via
PyErr_Warn.
msg60953 - (view) Author: Anthony Baxter (anthonybaxter) (Python triager) Date: 2006-11-07 06:03
Logged In: YES 
user_id=29957

Should we change these to all just default to a
SyntaxWarning? I agree that just spitting out warnings to
stderr is extremely suboptimal.
msg60954 - (view) Author: Anthony Baxter (anthonybaxter) (Python triager) Date: 2006-11-07 06:07
Logged In: YES 
user_id=29957

Neal points out there could be a bootstrapping problem if
warnings.py needs to be imported. We could do something like
check for 'warnings' in sys.modules, and still default to
stderr if it's not been imported. A more thorough fix is to
get warnings.py converted to C code, but that's going to be
a 2.6 thing, not a 2.5.1 thing.
msg113367 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2010-08-09 03:34
warning.py it still is in 3.1
msg154440 - (view) Author: Michele Orrù (maker) * Date: 2012-02-27 08:50
I am interested in solving this bug. 
If I understood correctly, that should be just a matter of spitting over sys.stdout whenever the user imports warnings.py, sys.stderr otherwise. 
Rewriting the code in C for python3.x would still be appreciated?
msg154483 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2012-02-27 15:58
Not quite, Michele. So this bug is about taking the stuff that is printed to stdout/stderr explicitly in parsetok.c and instead using the warnings functions, e.g. PyErr_Warn(), since _warnings is a built-in module (now) and thus is available to the tokenizer to use.
msg154939 - (view) Author: Michele Orrù (maker) * Date: 2012-03-05 09:56
For what I saw these days, Parser/tokenizer.c should import warnings.h (in order to use PyErr_WarnEx()), but Python/_warnings.c imports Python.h, that requires pgen ready. This leads to a circular dependency.

Am I wrong / missing something?
msg155111 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2012-03-07 20:03
It's quite possible you are right, Michele. I don't know if anyone has looked at what exactly is required for _warnings.c compared to pgen.
msg155384 - (view) Author: Michele Orrù (maker) * Date: 2012-03-11 14:29
May somebody check for this? Otherwise the bug could be considered invalid.
msg155388 - (view) Author: Jean-Paul Calderone (exarkun) * (Python committer) Date: 2012-03-11 15:38
> May somebody check for this? Otherwise the bug could be considered invalid.

This is not the proper workflow for bug tracking.  "No one is working on this right now" is not the same as "This bug is invalid".  No one worked on this ticket almost *seven years* after I filed it.

The "invalid" state in the issue tracker is for issues that have been filed that *do not describe a bug that exists at all* (or a feature is being rejected as a bad idea or something that will otherwise not be added to Python and will not be implemented).

Please do not close tickets as invalid just because no one is working on resolving them *right now*.  The purpose of closing issues is to keep track of useful development that is happening.  In and of itself, closing issues is a useless activity; it is only useful inasmuch as it reflects useful development.
msg155447 - (view) Author: Michele Orrù (maker) * Date: 2012-03-12 11:50
> This is not the proper workflow for bug tracking.  "No one is working 
> on this right now" is not the same as "This bug is invalid".  No one 
> worked on this ticket almost *seven years* after I filed it.
You are right. Sorry for that.
msg155555 - (view) Author: Sean Reifschneider (jafo) * (Python committer) Date: 2012-03-13 01:46
Michele: Do you know what needs to be done to determine the resolution to the _warnings/pgen question?  If not, maybe asking the question on python-dev could get some advice.
msg359754 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2020-01-10 20:51
Pablo, is this still a thing to care about?
msg359870 - (view) Author: Pablo Galindo Salgado (pablogsal) * (Python committer) Date: 2020-01-12 20:35
The C version of pgen is gone so the circular dependency should not be a problem as as far as I can tell, Parser/parsetok.c does not emit warnings anymore (the functions are unused). Maybe we should just clean that code instead.
msg359871 - (view) Author: Pablo Galindo Salgado (pablogsal) * (Python committer) Date: 2020-01-12 20:37
https://github.com/python/cpython/pull/17971
msg359899 - (view) Author: Pablo Galindo Salgado (pablogsal) * (Python committer) Date: 2020-01-13 11:59
Closed by https://github.com/python/cpython/pull/17365
History
Date User Action Args
2020-01-13 11:59:52pablogsalsetstatus: open -> closed
resolution: fixed
messages: + msg359899

stage: test needed -> resolved
2020-01-12 20:37:35pablogsalsetmessages: + msg359871
2020-01-12 20:35:39pablogsalsetmessages: + msg359870
2020-01-10 20:51:10brett.cannonsetnosy: + pablogsal
messages: + msg359754
2012-03-13 01:46:09jafosetnosy: + jafo
messages: + msg155555
2012-03-12 11:50:35makersetmessages: + msg155447
2012-03-11 15:38:06exarkunsetnosy: + exarkun
messages: + msg155388
2012-03-11 14:29:30makersetmessages: + msg155384
2012-03-07 20:03:32brett.cannonsetmessages: + msg155111
2012-03-05 09:56:42makersetmessages: + msg154939
2012-02-27 15:58:11brett.cannonsetmessages: + msg154483
2012-02-27 08:50:15makersetnosy: + ezio.melotti, eric.araujo, maker
messages: + msg154440
2012-02-25 15:42:05eric.araujosetversions: - Python 3.2
2012-02-24 11:04:59ezio.melottisetversions: + Python 3.3
2010-08-09 03:34:27terry.reedysetnosy: + terry.reedy

messages: + msg113367
versions: + Python 3.2, - Python 3.1, Python 2.7
2009-03-30 04:35:49ajaksu2setnosy: + brett.cannon
versions: + Python 3.1, Python 2.7, - Python 2.5

type: enhancement
stage: test needed
2006-07-30 21:37:34kurancreate