[issue21295] Python 3.4 gives wrong col_offset for Call nodes returned from ast.parse
Sven Brauch added the comment: But if you need the start of the full expression, can't you just go up in the "parent" chain until the parent is not an expression any more? Could additional API be introduced which provides the value I am looking for as well as the one you need? I was not on the nosy list by the way, I just put myself there after I commented. And that was after 3.4.3, after I noticed my software was suddenly broken by a patch release of python. -- ___ Python tracker <http://bugs.python.org/issue21295> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21295] Python 3.4 gives wrong col_offset for Call nodes returned from ast.parse
Sven Brauch added the comment: Hmm, strange, I did not receive any emails. "Incorrect" by what definition of incorrect? The word does not really help to clarify the issue you see with this change, since the behaviour was changed on purpose. What is the (preferably real-world) application which is broken by this change? -- ___ Python tracker <http://bugs.python.org/issue21295> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21295] Python 3.4 gives wrong col_offset for Call nodes returned from ast.parse
Sven Brauch added the comment: Why did you not CC me in this discussion? It is not very nice to have this behaviour changed back from what I relied upon in a minor version without notice. Which regression was effectively caused by this patch, except for the documentation being out of date? -- nosy: +scummos ___ Python tracker <http://bugs.python.org/issue21295> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 <http://bugs.python.org/issue10769> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 <http://bugs.python.org/issue10769> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16795] Patch: some changes to AST to make it more useful for static language analysis
Sven Brauch added the comment: Thanks for reviewing this, and thanks for guiding me through the implementation process. ;) -- ___ Python tracker <http://bugs.python.org/issue16795> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16795] Patch: some changes to AST to make it more useful for static language analysis
Sven Brauch added the comment: Hi Benjamin, the delay is not a problem -- as long as this is in time for Python 3.4, everything is fine. Attached is a patch which adjusts the unparser to the changes. Acoording to the tests, this is all that needs to be updated. Cheers, Sven -- Added file: http://bugs.python.org/file29445/81302-adjust-unparser.diff ___ Python tracker <http://bugs.python.org/issue16795> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16795] Patch: some changes to AST to make it more useful for static language analysis
Sven Brauch added the comment: I don't want to push anything, but did you find time to review this yet? It would be great to have it in the next release. -- ___ Python tracker <http://bugs.python.org/issue16795> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16795] Patch: some changes to AST to make it more useful for static language analysis
Sven Brauch added the comment: Oh, alright, that explains things. In this case, the file I attached on Jan 29 (http://bugs.python.org/file28905/81300-change-var-kwargs-new.diff) should contain all the requested changes. Greetings -- ___ Python tracker <http://bugs.python.org/issue16795> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16795] Patch: some changes to AST to make it more useful for static language analysis
Sven Brauch added the comment: Attaching files to this bug report here works fine (see corrected patch above), but when I add the file to http://bugs.python.org/review/16795/ under "Add another patchset", I get the error message I described. I tried with firefox, chromium and konqueror. -- ___ Python tracker <http://bugs.python.org/issue16795> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16795] Patch: some changes to AST to make it more useful for static language analysis
Sven Brauch added the comment: Any news on this yet? ;) Unfortunately, I'm still having no luck in adding the patch to the review tool (same error message). -- ___ Python tracker <http://bugs.python.org/issue16795> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16795] Patch: some changes to AST to make it more useful for static language analysis
Sven Brauch added the comment: Hm, I'm still getting the same error messages from the review tool which I described earlier; I can neither comment nor add patches. So, I'll have to abuse the bug report again: Thanks for the review. Is it possible you selected the wrong patch file for the second patch (Patch Set 5)? It seems to include all changes instead of just those from the second of the three patches I submitted. Also I had already removed the traceback.print_stack() call. I fixed the other two issues and I will attach a corrected version of the second patch for review. I hope I got everything right ;) Please have an extra close look at the changes to symtable.c and compile.c (since I'm not very familiar with that code), in order to avoid that we break stuff with this. Cheers, Sven -- Added file: http://bugs.python.org/file28905/81300-change-var-kwargs-new.diff ___ Python tracker <http://bugs.python.org/issue16795> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16795] Patch: some changes to AST to make it more useful for static language analysis
Sven Brauch added the comment: I have signed the contributor agreement and sent a scan to the specified mail address (received no reply so far, but I guess that's okay). Did anyone happen to find the time to look at the patches yet? Greetings, Sven -- ___ Python tracker <http://bugs.python.org/issue16795> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16795] Patch: some changes to AST to make it more useful for static language analysis
Sven Brauch added the comment: third patch file (... is there a better way to upload three files?) -- Added file: http://bugs.python.org/file28789/81301-change-attr-ranges.diff ___ Python tracker <http://bugs.python.org/issue16795> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16795] Patch: some changes to AST to make it more useful for static language analysis
Sven Brauch added the comment: second patch file -- Added file: http://bugs.python.org/file28788/81300-change-var-kwargs.diff ___ Python tracker <http://bugs.python.org/issue16795> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16795] Patch: some changes to AST to make it more useful for static language analysis
Sven Brauch added the comment: Okay, here they are. I'm not sure how to make hg include a commit message in the patch... 81299-extend-asdl.diff: Changes required to the ASDL framework, in order to allow attributes ( ... ) on a product 81300-change-var-kwargs.diff: Makes var/kwarg be instances of arg, and adds the lineno / col_offset attributes to arg. 81301-change-attr-ranges.diff: Changes power ranges as described in the first post of this report. All three patches include the corresponding changes to the unit tests, and hopefully the correct set of changes to the generated (Python-ast.h/.c) files. -- Added file: http://bugs.python.org/file28787/81299-extend-asdl.diff ___ Python tracker <http://bugs.python.org/issue16795> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16795] Patch: some changes to AST to make it more useful for static language analysis
Sven Brauch added the comment: Alright, I'll be back with those shortly (as soon as I found out how to do this best with hg -- I'm used to git ;). I'll also sign the contributor agreement, that's no problem of course. -- ___ Python tracker <http://bugs.python.org/issue16795> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16795] Patch: some changes to AST to make it more useful for static language analysis
Sven Brauch added the comment: Here's the next version which I hope to be somewhat complete now. vararg and kwarg are now of type arg, and I did all the changes which are required to make this possible. The ast tests pass. Do you prefer to have this as one large patch all together, or would you rather like to review (and apply) 3..4 patches split into the individual features I implemented? -- Added file: http://bugs.python.org/file28786/full3.diff ___ Python tracker <http://bugs.python.org/issue16795> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16795] Patch: some changes to AST to make it more useful for static language analysis
Sven Brauch added the comment:
I think I got it mostly working now (it was quite simple in fact), but there's
one issue which I can't seem to solve. This fails:
>>> compile(ast.parse("def fun(): pass"), "", "exec")
Traceback (most recent call last):
File "", line 1, in
TypeError: required field "arg" missing from arg
However, this succeeds:
>>> compile(ast.parse("def fun(*va, **kwa): pass"), "", "exec")
at 0x7fb390323780, file "", line 1>
The reason is quite simple: vararg and kwarg are optional in arguments, but
they're of type arg, and arg has mandatory attributes ("arg", the name of the
argument). Still, when calling ast.parse(), Python creates attributes called
vararg, kwarg on the "attributes" object, which are set to None:
>>> ast.parse('def fun(): pass').body[0].args.vararg.__repr__()
'None'
Thus, when in compile(), the code in Python_ast.c does "if (
_PyObject_HasAttrId(obj, &PyId_vararg) ) { ... }" this check says "yes there's
a vararg" altough there really is none, which leads to the above error message.
I checked the asdl file, and in fact I think this is a general issue, which was
not noticed so far, since only things without mandatory attributes are used in
conjunction with the question mark "?" operator there (expr and the integral
types identifier, int...). Is this correct?
An easy way to solve this problem would be to check whether the attribute is
None in Python_ast.c, but I'm everything but sure this is the correct way to
fix this. Alternatively, one could not create the attributes on the ast objects
when they're not present in the parsed code (i.e. leave the "vararg" attribute
nonexistent instead of setting it to none). What should I do about this?
--
___
Python tracker
<http://bugs.python.org/issue16795>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16795] Patch: some changes to AST to make it more useful for static language analysis
Sven Brauch added the comment: Not an issue, having this thing resolved upstream would save a huge lot of pain elsewhere. ;) So, to make sure... I'll go to the asdl file, make arguments have two arg attributes which store the data for the var and kwarg which they can contain, then I adjust ast.c to reflect that new structure. Then I go to asdl.py and hack it so we can have attributes ( ... ) on arguments. Does that sound correct? -- ___ Python tracker <http://bugs.python.org/issue16795> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16795] Patch: some changes to AST to make it more useful for static language analysis
Sven Brauch added the comment: Ah, whops, I misunderstood that. The error is rather generic: Traceback (most recent call last): File "./Lib/test/test_ast.py", line 796, in test_lambda self._check_arguments(fac, self.expr) File "./Lib/test/test_ast.py", line 596, in _check_arguments check(arguments(args=args), "must have Load context") File "./Lib/test/test_ast.py", line 593, in arguments kwarg, kwargannotation, defaults, kw_defaults) TypeError: arguments constructor takes either 0 or 12 positional arguments It's very generic in C too: Python/ast.c:1571:42: error: macro "arguments" requires 13 arguments, but only 9 given -- ___ Python tracker <http://bugs.python.org/issue16795> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16795] Patch: some changes to AST to make it more useful for static language analysis
Sven Brauch added the comment: The above post has an example for trying to add a patch, here's what happens when I try to post a reply: http://pastie.org/pastes/5665144/text I also tried with another web browser, so it's unlikely that it's the browser's fault (but maybe the user's? ;) -- ___ Python tracker <http://bugs.python.org/issue16795> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16795] Patch: some changes to AST to make it more useful for static language analysis
Sven Brauch added the comment: The patch review tool currently throws errors on submitting any form (http://pastie.org/pastes/5665048/text) so please forgive me for answering here once more. I'll copy this information (patch + message) to the review as soon as the website is working again. > In ast.c, use the LINENO macro for n_lineno. Done. > http://bugs.python.org/review/16795/diff/7080/Lib/test/test_ast.py#newcode183 > Lib/test/test_ast.py:183: def _assertTrueorder(self, ast_node, parent_pos, reverse_check = False): > Wrap everything here by 80 chars. Done. > http://bugs.python.org/review/16795/diff/7080/Lib/test/test_ast.py#newcode198 > Lib/test/test_ast.py:198: self.assertTrue(node_pos <= parent_pos if > reverse_check else node_pos >= parent_pos) > Lift the condition out of the assert call. Done. > http://bugs.python.org/review/16795/diff/7080/Lib/test/test_ast.py#newcode467 > Lib/test/test_ast.py:467: self.maxDiff = None > A comment explaining what this is for would be nice. Sorry, this was for testing purposes only, and I forgot to remove it. > http://bugs.python.org/review/16795/diff/7080/Lib/test/test_ast.py#newcode589 > Lib/test/test_ast.py:589: 0, 0, 0, 0) > These extra parameters are optional now, right? They needn't be passed > then. Unfortunately not: Altough the question mark in the asdl file is present and I made fairly sure to regenerate all the derived files, the parameters are still mandatory. URL of the patch review: http://bugs.python.org/review/16795/ -- Added file: http://bugs.python.org/file28681/full2.diff ___ Python tracker <http://bugs.python.org/issue16795> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16795] Patch: some changes to AST to make it more useful for static language analysis
Sven Brauch added the comment: Attached is the full diff this time. -- Added file: http://bugs.python.org/file28680/full.diff ___ Python tracker <http://bugs.python.org/issue16795> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16795] Patch: some changes to AST to make it more useful for static language analysis
Sven Brauch added the comment: Here's another version now which I think could be used like this. All tests have been adjusted. I'll append two patches, one just containing the changes to the parser for ease of review, and one full diff which also contains changes to the generated files and the test adjustments. Please point out any remaining problems you see with this so I can fix them. -- Added file: http://bugs.python.org/file28679/readable.diff ___ Python tracker <http://bugs.python.org/issue16795> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16795] Patch: some changes to AST to make it more useful for static language analysis
Sven Brauch added the comment: Here's a new proposal, I adjusted the AST tests and fixed some small problems I encountered during that. It contains all the diffs for generated files, should I remove those for easier review? A remaining problem is that AST_Tests::_assertTrueorder now fails, I think because the condition it checks simply is not met any more (by design of the change). What's the correct way to deal with that? -- Added file: http://bugs.python.org/file28596/python2.diff ___ Python tracker <http://bugs.python.org/issue16795> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16795] Patch: some changes to AST to make it more useful for static language analysis
Sven Brauch added the comment: Thanks. I had seen and tried this before, but the "ast" module in python, which is used in the tests, still requires the additional arguments. Probably this is only valid for the C API? -- ___ Python tracker <http://bugs.python.org/issue16795> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16795] Patch: some changes to AST to make it more useful for static language analysis
Sven Brauch added the comment: While writing tests, I noticed that the additional fields (lineno, col_offset for vararg, kwarg, and other arguments) currently are mandatory. Is that a problem? It doesn't seem trivial to change that, since apparently only attributes (not fields) can be optional, but those are not allowed by the syntax of python.asdl at this point. In case the fields need to be mandatory, what would be the correct approach to achieve that? Thanks. -- ___ Python tracker <http://bugs.python.org/issue16795> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16795] Patch: some changes to AST to make it more useful for static language analysis
New submission from Sven Brauch: Here's a patch doing some adjustments to the AST to make it more useful for static language analysis, as discussed in http://mail.python.org/pipermail/python-dev/2012-December/123320.html. Changes done: * the described fix to attribute ranges * add location information for var / kwargs and arguments Interestingly, this even fixes a bug; compare the locations of the error in the following situation: >>> l = [1, 2, 3] >>> l[ ... ... 2 ... ... ].Foo Old error message: Traceback (most recent call last): File "", line 3, in AttributeError: 'int' object has no attribute 'Foo' New error message: Traceback (most recent call last): File "", line 5, in AttributeError: 'int' object has no attribute 'Foo' The new message is obviously more accurate (one could even go as far as saying that the first one does not make any sense at all -- what does the expression in the slice have to do with the error?). The same thing happens in similar situations, e.g. with line continuation characters, function calls, ... anything multi-line with an error related to attribute access. I hope the patch is okay, if not please let me know what to change. I also hope I managed to include all important changes into the patch ;) -- components: None files: python.diff keywords: patch messages: 178339 nosy: scummos priority: normal severity: normal status: open title: Patch: some changes to AST to make it more useful for static language analysis versions: Python 3.4 Added file: http://bugs.python.org/file28462/python.diff ___ Python tracker <http://bugs.python.org/issue16795> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 <http://bugs.python.org/issue10769> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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-12-26 13:25:48.0 +0100
@@ -1742,8 +1742,6 @@
tmp = ast_for_trailer(c, ch, e);
if (!tmp)
return NULL;
-tmp->lineno = e->lineno;
-tmp->col_offset = e->col_offset;
e = tmp;
}
if (TYPE(CHILD(n, NCH(n) - 1)) == factor) {
The offsets for "foo.bar.baz" before the patch:
[1, 0, <_ast.Attribute>]
[1, 0, <_ast.Attribute>, 'baz']
[1, 0, <_ast.Name>, 'bar']
[1, 0, 'foo']
... and after the patch:
[1, 0, <_ast.Attribute>]
[1, 7, <_ast.Attribute>, 'baz']
[1, 3, <_ast.Name>, 'bar']
[1, 0, 'foo']
It would really be great if that could be applied.
Best regards,
Sven
--
___
Python tracker
<http://bugs.python.org/issue10769>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 any more useful than now is simply invalid, because I got an application here which would work with, but not without the change, and I didn't yet see one for the other side. Best regards, Sven -- ___ Python tracker <http://bugs.python.org/issue10769> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 just copied from foo to blah. Anyway, I'd like to get away from this abstract discussion which is not likely to yield a result... is there any reason not to do it like I suggested other than the philosophical "it's wrong"? Or don't you agree that the information given this way would be more useful? Best regards, Sven -- ___ Python tracker <http://bugs.python.org/issue10769> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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) AST created for b, c, and d which contains their ranges. Why isn't it like this for attributes? I also don't really see a reason why those ranges shouldn't be changed for all possible cases (subscript / call / attribute). It will contain more information while not taking any more memory or such, and it will be more intuitive. You can still get the information on where the expression starts by going up the chain to the next Expression AST node, which seems much more logical to me than storing this -- rarely useful -- information redundantly in maybe dozens of nodes. After all, the ast module is meant for "end users" to base applications on it, isn't it? Otherwise, you should at least be consistent and remove that range information from the tree completely, because there's absolutely *no* case in which it would ever be useful (at least I cannot think of one). Best regards, Sven -- ___ Python tracker <http://bugs.python.org/issue10769> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 correctly set before!) is being discarded and replaced by the useless information from the expression ast. I don't see any reason for this, is there one? :) Removing those two lines doesn't seem to break anything and sets ranges correctly. Best regards, Sven -- ___ Python tracker <http://bugs.python.org/issue10769> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 to find out what changes would be needed in the code to make the col_offset attribute useful in this case. Best regards, Sven -- ___ Python tracker <http://bugs.python.org/issue10769> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 easiest way -- which is okay, of course, but is not a valid reason not to change it now. It's also not that there's fifty things missing to make it fully functional for the purpose of highlighting / analyzing the code, this is about the only one. :) Best regards, Sven -- ___ Python tracker <http://bugs.python.org/issue10769> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 highlighting (or whatever); for example, class_instance.method(argument1.arg_attribute).attribute class_instance.method( argument1.arg_attribute). attribute and class_instance.method( argument1. \ arg_attribute) \ . attribute produce exactly the same syntax tree, making it impossible to determine where e.g. "attribute" starts and ends. Although technically obviously correct, the information that the column offset for "attribute" is "0" is quite pointless. It would really be great if there could be an additional attribute for Attribute Access nodes which tells me where the attribute access the node refers to *really* takes place, not just "column 0". :) It would be even better if there was not only an offset, but also an "end" attribute providing information on where the node ends; that'd make this module way more useful, at least for me. Thanks and best regards, Sven -- components: Library (Lib) messages: 124596 nosy: georg.brandl, scummos priority: normal severity: normal status: open title: ast: provide more useful range information type: feature request ___ Python tracker <http://bugs.python.org/issue10769> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
