Warnings should be emitted with the warning system, via
PyErr_Warn.

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.

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.

warning.py it still is in 3.1

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?

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.

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?

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.

May somebody check for this? Otherwise the bug could be considered invalid.

> 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.

> 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.

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.

Pablo, is this still a thing to care about?

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.

https://github.com/python/cpython/pull/17971

Closed by https://github.com/python/cpython/pull/17365