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 scummos
Recipients benjamin.peterson, georg.brandl, rhettinger, scummos, terry.reedy
Date 2010-12-25.10:49:46
SpamBayes Score 2.220446e-16
Marked as misclassified No
Message-id <1293274190.95.0.354180098598.issue10769@psf.upfronthosting.co.za>
In-reply-to
Content
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
History
Date User Action Args
2010-12-25 10:49:51scummossetrecipients: + scummos, georg.brandl, rhettinger, terry.reedy, benjamin.peterson
2010-12-25 10:49:50scummossetmessageid: <1293274190.95.0.354180098598.issue10769@psf.upfronthosting.co.za>
2010-12-25 10:49:46scummoslinkissue10769 messages
2010-12-25 10:49:46scummoscreate