This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: Add BLANK_LINE to
Type: Stage:
Components: Library (Lib) Versions:
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: jhylton Nosy List: jhylton, loewis, logistix
Priority: normal Keywords: patch

Created on 2004-11-20 21:58 by logistix, last changed 2022-04-11 14:56 by admin. This issue is now closed.

File name Uploaded Description Edit
token.patch logistix, 2004-11-20 21:58 patch for
Messages (3)
msg47314 - (view) Author: Grant Olson (logistix) Date: 2004-11-20 21:58
The parser module generates an ast node number 54 for 
an entirely blank line.  These lines are apparently ignored 
by the real parser, and don't have a real definition in 
include\token.h.  Presumably because of that they don't 
have an entry in

However, this broke an app where I hardcoded the 
number and recent language features have changed the 
mapping of numbers to token names.

I think there should be a BLANK_LINE defined in 
so that it can be referred to by name, even if it's not 
used in the real parser.  While dealing with parsermodule 
generated ast-trees, "symbol.sym_name[node] or 
token.tok_name[node]" should always be true.
msg47315 - (view) Author: Grant Olson (logistix) Date: 2004-11-22 00:41
Logged In: YES 

A few clarifications:

On further review, the node number 54 comes from, not the parsermodule.

I also meant to say that "symbol.sym_name.has_key(node) or 
token.tok_name.has_key(node)" should always be true.
msg47316 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2006-11-19 08:33
As you found yourself, the patch is wrong. This token type is already exposed from tokenize as tokenize.NL; if you use tokenize, you should use its list of token types, not the one of

Closing this patch as rejected.
Date User Action Args
2022-04-11 14:56:08adminsetgithub: 41202
2004-11-20 21:58:24logistixcreate