Repository navigation
Allow connecting AST nodes with corresponding source ranges #66806
Description
| BPO | 22616 |
|---|---|
| Nosy | @edreamleo, @bitdancer, @aivarannamaa, @ilevkivskyi |
| Superseder |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = None
closed_at = <Date 2019-01-14.11:24:06.782>
created_at = <Date 2014-10-12.07:35:07.593>
labels = ['interpreter-core', 'type-feature']
title = 'Allow connecting AST nodes with corresponding source ranges'
updated_at = <Date 2019-01-14.12:19:22.360>
user = 'https://github.com/aivarannamaa'bugs.python.org fields:
activity = <Date 2019-01-14.12:19:22.360>
actor = 'edreamleo'
assignee = 'none'
closed = True
closed_date = <Date 2019-01-14.11:24:06.782>
closer = 'levkivskyi'
components = ['Interpreter Core']
creation = <Date 2014-10-12.07:35:07.593>
creator = 'Aivar.Annamaa'
dependencies = []
files = []
hgrepos = []
issue_num = 22616
keywords = []
message_count = 7.0
messages = ['229124', '229127', '229138', '229152', '229164', '333609', '333614']
nosy_count = 5.0
nosy_names = ['edreamleo', 'r.david.murray', 'Aivar.Annamaa', 'Edward.K..Ream', 'levkivskyi']
pr_nums = []
priority = 'normal'
resolution = None
stage = 'resolved'
status = 'closed'
superseder = '33416'
type = 'enhancement'
url = 'https://bugs.python.org/issue22616'
versions = ['Python 3.5']
Activity
aivarannamaa commentedon Oct 12, 2014
Currently lineno and col_offset attributes in AST nodes have confusing roles. According to documentation they indicate the starting position of node's source text but according to recent developments (bpo-16795) they seem to indicate a position most suitable to use in error messages related to that node (rather narrow goal IMO).
Another problem is that currently the AST nodes don't contain any information about the end position of corresponding source text. Therefore it's very difficult to relate nodes with source. One could want to do this for example in advanced graphical debuggers (https://bitbucket.org/plas/thonny)
I propose adding new attributes to AST nodes which indicate the corresponding source range. If you want to keep nodes lightweight by default, then you could also introduce a flag in ast.parse for getting these attributes.
The range could be given either in token indices or in character positions (or both). This probably needs more discussion. (I would vote against pointers to UTF-8 bytes, as is the case with col_offset currently.)
bitdancer commentedon Oct 12, 2014
If it needs some discussion, perhaps it should be raised on python-ideas first. My reading of bpo-16795 (granted I only skimmed it) was that improving the error messages was a *side effect* of making the position information more accurate (in the context of static analysis tools).
Also, unless you intend to work on a patch this isn't likely to go anywhere :)
EdwardKReam commentedon Oct 12, 2014
I urge the Python development team to fix this and the related bugs given in the Post Script. The lack of an easy way of associating ast nodes with text ranges in the original sources is arguably the biggest hole in the Python api.
These bugs have immediate, severe, practical consequences for any tool that attempts to regularize (PEP-8) or beautify Python code.
Consider the code for PythonTidy:
http://lacusveris.com/PythonTidy/PythonTidy-1.23.python
Every version has had bugs in this area arising from difficult workarounds to the hole in the API. The entire Comments class is a horror directly related to these issues.
Consider Aivar's workaround to these bugs:
https://bitbucket.org/plas/thonny/src/8cdaa41aca7a5cc0b31618b6f1631d360c488196/src/ast_utils.py?at=default
See the docstring for def fix_ast_problems. This is an absurdly difficult solution to what should be a trivial problem.
It's impossible to build reliable software using such heroic hacks. The additional bugs listed below further complicate a nightmarish task.
In short, these bugs are *not* minor little nits. They are preventing the development of reliable source-code tools.
Edward K. Ream
P.S. Here are the related bugs:
http://bugs.python.org/issue10769
Allow connecting AST nodes with corresponding source ranges
http://bugs.python.org/issue21295
Python 3.4 gives wrong col_offset for Call nodes returned from ast.parse
http://bugs.python.org/issue18374
ast.parse gives wrong position (col_offset) for some BinOp-s
http://bugs.python.org/issue16806
col_offset is -1 and lineno is wrong for multiline string expressions
EKR
bitdancer commentedon Oct 12, 2014
The "python develop team" is a group of volunteers. What you need to do to move this forward is to work on patches (or polishing patches, in the case of bpo-16806) for open issues for which there has been no objection, and build a consensus for fixing the issues for which there has been objection.
Based on the bpo-10769 discussion, it sounds like it would be worthwhile to go to python-ideas and advocate for the position that the ast parser should be enhanced for the kind of use cases you are talking about. It is possible a PEP would be required, but it is also fairly likely that one will not be.
Personally I'm in favor of supporting such use cases, but I'm not involved in maintaining any of the relevant code nor do I have an interest in getting involved at this time.
bitdancer commentedon Oct 12, 2014
OK, reading the followon links just added to issue bpo-10769, it seems clear you don't need to advocate for the idea of supporting external tools, there seems to be consensus agreement for that. So now it is down to specific proposals and patches. And reviews of patches, those are equally important :)
ilevkivskyi commentedon Jan 14, 2019
Closed as superseded by https://bugs.python.org/issue33416
edreamleo commentedon Jan 14, 2019
On Mon, Jan 14, 2019 at 5:24 AM Ivan Levkivskyi <[email protected]>
wrote:
Adding endline and endcolumn to every ast node will be a big improvement.
Edward
------------------------------------------------------------------------------------------
Edward K. Ream: [email protected] Leo: http://leoeditor.com/
------------------------------------------------------------------------------------------