[issue10769] ast: provide more useful range information

R. David Murray added the comment: Thanks. -- stage: needs patch -> resolved ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue10769] ast: provide more useful range information

Sven Brauch added the comment: Yes, this issue can be closed. -- resolution: -> fixed status: open -> closed ___ Python tracker ___ _

[issue10769] ast: provide more useful range information

R. David Murray added the comment: OK, so that patch was committed. Does that mean this one can be close? (I'm not familiar with the code in question.) -- ___ Python tracker _

[issue10769] ast: provide more useful range information

Sven Brauch added the comment: Hi, Mailing list thread: https://mail.python.org/pipermail/python-dev/2012-December/123320.html Discussion on the patch: http://bugs.python.org/issue16795 Greetings, Sven -- ___ Python tracker

[issue10769] ast: provide more useful range information

R. David Murray added the comment: If there was a python-ideas or python-dev thread that resulted in consensus approval of this change, can someone post a link to it? -- nosy: +r.david.murray ___ Python tracker __

[issue10769] ast: provide more useful range information

Changes by Ethan Furman : -- nosy: +ethan.furman ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.p

[issue10769] ast: provide more useful range information

Michael added the comment: Hi, Attached is the updated patch by Sven Brauch from the original mailing list thread bringing column offset reporting for attributes in line with everything else. The offsets for bar before the patch: foo[bar] = 4 foo(bar) = 4 foo.bar = 0 After: foo[bar] = 4 fo

[issue10769] ast: provide more useful range information

Sven Brauch added the comment: Okay, thank you, I'm going to do that. :) Bye, Sven -- ___ Python tracker ___ ___ Python-bugs-list ma

[issue10769] ast: provide more useful range information

Benjamin Peterson added the comment: I suggest you mail python-dev or python-ideas. I find it more consistent as it stands now. -- ___ Python tracker ___ __

[issue10769] ast: provide more useful range information

Sven Brauch added the comment: Hi, yeah Terry, that's exactly what most people whom I talked about this said (me too). Anyway, here's the patch which -- in my opinion -- fixes this behavior: --- python-orig/Python/ast.c 2010-10-19 03:22:07.0 +0200 +++ python-ast-fix/Python/ast.c 2010

[issue10769] ast: provide more useful range information

Terry J. Reedy added the comment: FWIW, I find the current behavior for attributes to be surprising, to the point where at first glance it almost looks like a bug. Which is to say, I would have expected 'col' to point to the first non-whitespace column after the '.'. If there are multiple att

[issue10769] ast: provide more useful range information

Sven Brauch added the comment: Then you'd get the point where foo starts instead of the location of the opening brace. Sounds good for me. Also, I already said that, with the change I proposed, I do not see any case where relevant information would be lost. Your argument that it would not be

[issue10769] ast: provide more useful range information

Benjamin Peterson added the comment: 2010/12/25 Sven Brauch : > > Sven Brauch added the comment: > > Well, weather it's supposed to or not, it *does* contain the line number > information: > > For your example, the AST for "foo" tells you the offset for foo. If you want > to know the offset

[issue10769] ast: provide more useful range information

Sven Brauch added the comment: Well, weather it's supposed to or not, it *does* contain the line number information: For your example, the AST for "foo" tells you the offset for foo. If you want to know the offset (well, "offset") for blah, why not look at foo? Currently, the information is

[issue10769] ast: provide more useful range information

Benjamin Peterson added the comment: 2010/12/25 Sven Brauch : > > Sven Brauch added the comment: > > Hi, > > I agree that the current behavior is not wrong or such. It's just entirely > useless. > For all the other types of subscripts, such as a[b][c][d] or a(b)(c)(d), the > ranges of the act

[issue10769] ast: provide more useful range information

Sven Brauch added the comment: Hi, I agree that the current behavior is not wrong or such. It's just entirely useless. For all the other types of subscripts, such as a[b][c][d] or a(b)(c)(d), the ranges of the actual subscript ASTs are also nulled, but there's an additional Name (or whatever

[issue10769] ast: provide more useful range information

Benjamin Peterson added the comment: 2010/12/24 Sven Brauch : > > Sven Brauch added the comment: > > Hi, > > I found the reason for this behavior in the code now, it's in Python/ast.c, > lines 1745 and 1746 in ast_for_power(): > >        tmp->lineno = e->lineno; >        tmp->col_offset = e->c

[issue10769] ast: provide more useful range information

Sven Brauch added the comment: Hi, I found the reason for this behavior in the code now, it's in Python/ast.c, lines 1745 and 1746 in ast_for_power(): tmp->lineno = e->lineno; tmp->col_offset = e->col_offset; Here, the range information for the individual attributes (which is

[issue10769] ast: provide more useful range information

Sven Brauch added the comment: Hi Terry, well, the current behaviour is... logical in some way, as it says "the whole expression which accesses an attribute starts at column 0", i.e. it's easy to understand why it's done like this. It just turns out that this is pretty useless... I'll try t

[issue10769] ast: provide more useful range information

Terry J. Reedy added the comment: A request limited only to fixing the current field for attribute may get more traction than a request for a new field. Can you dig into to code to get any idea why the difference between attributes versus indexes and parameters? -- nosy: +terry.reedy

[issue10769] ast: provide more useful range information

Sven Brauch added the comment: Hi, well, but you have to agree that there is no point in setting a correct column offset for bar in foo[bar] (it's correctly set to 4 here!) and foo(bar) but not for foo.bar (there's no information provided here) For me, this looks like it was just done the eas

[issue10769] ast: provide more useful range information

Raymond Hettinger added the comment: If info fields are added, they need to be optional so that someone manipulating the tree (adding, rearranging, or removing nodes) doesn't have an additional burden of supplying this info before compiling into an executable code object. --

[issue10769] ast: provide more useful range information

Benjamin Peterson added the comment: 2010/12/24 Raymond Hettinger : > > Raymond Hettinger added the comment: > > ISTM the whole point of an Abstract Syntax Tree is to express semantics while > throwing away the syntax details.  The only reason any position information > is kept is to support

[issue10769] ast: provide more useful range information

Raymond Hettinger added the comment: ISTM the whole point of an Abstract Syntax Tree is to express semantics while throwing away the syntax details. The only reason any position information is kept is to support tracebacks and debugging. Perhaps the OP's request should changed to "add func

[issue10769] ast: provide more useful range information

Changes by R. David Murray : -- nosy: +benjamin.peterson stage: -> needs patch versions: +Python 3.3 ___ Python tracker ___ ___ Pytho

[issue10769] ast: provide more useful range information

New submission from Sven Brauch : Hi, I'm writing a python language support plugin for an IDE. I'm using the AST module to get information about the loaded source code, which works pretty well. However, in some cases, the information provided by the AST is simply not sufficient to do proper h