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.

Author benjamin.peterson
Recipients benjamin.peterson, georg.brandl, rhettinger, scummos, terry.reedy
Date 2010-12-25.14:29:24
SpamBayes Score 1.11022e-16
Marked as misclassified No
Message-id <>
In-reply-to <>
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 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?

Because those can take any Python expression. Attributes only ever take a name.

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

Expr is just a container node. It's not supposed to store extra information.

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

That's not the case here:

x = foo.blah
Date User Action Args
2010-12-25 14:29:25benjamin.petersonsetrecipients: + benjamin.peterson, georg.brandl, rhettinger, terry.reedy, scummos
2010-12-25 14:29:24benjamin.petersonlinkissue10769 messages
2010-12-25 14:29:24benjamin.petersoncreate