Add .end_lineno attribute to pyclbr _Objects #82488
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
assignee = None closed_at = <Date 2022-03-19.08:04:21.182> created_at = <Date 2019-09-28.17:26:30.267> labels = ['type-feature', 'library', '3.10'] title = 'Add .end_lineno attribute to pyclbr _Objects' updated_at = <Date 2022-03-19.08:04:21.182> user = 'https://github.com/kebab-mai-haddi'
activity = <Date 2022-03-19.08:04:21.182> actor = 'iritkatriel' assignee = 'none' closed = True closed_date = <Date 2022-03-19.08:04:21.182> closer = 'iritkatriel' components = ['Library (Lib)'] creation = <Date 2019-09-28.17:26:30.267> creator = 'aviral' dependencies =  files =  hgrepos =  issue_num = 38307 keywords = ['patch'] message_count = 8.0 messages = ['353467', '353468', '385657', '385807', '385814', '385816', '385819', '386085'] nosy_count = 5.0 nosy_names = ['terry.reedy', 'steven.daprano', 'brandtbucher', 'aviral', 'kebab-mai-haddi'] pr_nums = ['16466', '24348'] priority = 'normal' resolution = 'fixed' stage = 'resolved' status = 'closed' superseder = None type = 'enhancement' url = 'https://bugs.python.org/issue38307' versions = ['Python 3.10']
The text was updated successfully, but these errors were encountered:
3.6 is in feature-freeze. The earliest that any enhancement could be added is version 3.9.
Can you explain how having an ending line number as well as the starting line number can be used to check which imports are used in a class?
The answer, Aviral discovered, is that current ast nodes have end_lineno attributes, so the patch amounts to consistently copying them.
I don't understand Aviral's use case either, but an item on my IDLE wish list is to be able to move class and function definitions within a file by moving the Class and Function entries within the browser tree. This requieres end lines and having it be an attribute is easier and more accurate than recalculating it. Merely clicking on an entry could highlight the whole definition. Other people might think of other uses.
An issue in the patch is inserting parameter 'end_line' after 'line'. Normally, new parameters have to go at the end, but:
I posted "What is the pyclbr public API" to pydev asking about this issue.
Hey Terry, thanks for commenting. I have a few questions to ask you, please pardon my lack of awareness.
How do you recalculate the end_lineno?
Since all the objects that start, have an end too, would
I could not make anything out of your third point where you mention
Can you share the link of your post?
As for my use case, I need the scope of a class and a function in the new tool that I am developing. My tool is to generate a new type of UML diagrams for a given codebase. Do check it out and leave your critical feedback: https://github.com/kebab-mai-haddi/gruml
I need to know about the scope (start and end) so that I can deduce whether the "used_at" attribute of an object is within a class. This will help me deduce whether a particular class (or a function) uses any imported object. This is to deduce the dependency of a class on other classes and functions.
Currently, I have to edit the pyclbr and make it custom, then, had to Dockerize the whole thing. So, want to contribute to
If IDLE were to recalculate the end from start, it would have to more or less parse forward to find the end of the statement. This is why I considered it a speculative wish.
Point 3: The existing doc implies but does not exactly state that the _Object signature are private, so that we could break any possibly existing (but possibly not, and discouraged) use. I think back-compatibility is discussed in the devguide.
Posts do not have a link until distributed, and then you can find it on mail.python.org. The title is sufficient to do that.