[issue38307] Add .end_lineno attribute to pyclbr _Objects

[Irit Katriel]

Change by Irit Katriel :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38307] Add .end_lineno attribute to pyclbr _Objects

[Terry J. Reedy]

Terry J. Reedy  added the comment:


New changeset 000cde59847beaf5fa7b73633e1f3c898fe5bf90 by Aviral Srivastava in 
branch 'master':
bpo-38307: Add end_lineno attribute to pyclbr Objects (GH-24348)
https://github.com/python/cpython/commit/000cde59847beaf5fa7b73633e1f3c898fe5bf90


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38307] Add .end_lineno attribute to pyclbr _Objects

[Terry J. Reedy]

Terry J. Reedy  added the comment:

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.

> would `end_lineno=None` make any sense?  
Only as a kludge if a default were required because of the signature position.

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38307] Add .end_lineno attribute to pyclbr _Objects

[Aviral Srivastava]

Aviral Srivastava  added the comment:

Hey Terry, thanks for commenting. I have a few questions to ask you, please 
pardon my lack of awareness.

>This requieres end lines and having it be an attribute is easier and more 
>accurate than recalculating it.

How do you recalculate the end_lineno?


Since all the objects that _start_, have an _end_ too, would `end_lineno=None` 
make any sense?


I could not make anything out of your third point where you mention `readline` 
and `readline_ex`. Can you explain that point?


>I posted "What is the pyclbr public API" to pydev asking about this issue.

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 `cpython` so that this feature is 
present at the source itself.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38307] Add .end_lineno attribute to pyclbr _Objects

[Terry J. Reedy]

Terry J. Reedy  added the comment:

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:

1. Inserting 'end_line' after 'line' makes the code easier to read.

2. The parameter or parameters at the end have default values.  If we added 
'end_line=None', we would have to consider what to do when it is omitted.

3. https://docs.python.org/3/library/pyclbr.html#module-pyclbr, which I rewrote 
in 2017, documents readline and readline_ex as the public call interface.  They 
return a hierarchical structure that includes Functions and Classes in the dict 
values.  Their signatures are intentionally omitted and the attributes are only 
listed after saying "Users are not expected to create instances of these 
classes."

I posted "What is the pyclbr public API" to pydev asking about this issue.

--
nosy: +terry.reedy
title: Provide Class' end line in pyclbr module -> Add .end_lineno attribute to 
pyclbr _Objects
versions: +Python 3.10 -Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com