It's likely that the additions are going to break someone's code; the question seems to be do we care, since the constructors are undocumented?

But shouldn't we just document the signatures, so that in the future we're not going to make the same mistake?

I also wonder if some judicious use of keyword-only args might help users who currently call the old constructors catch the breakage where it's easily diagnosed (i.e. at the call site) instead of once the object is instantiated (e.g. "why is end_lineno/parent the wrong type")?

Perhaps even add some type checks to catch obvious mistakes (could be as simple as `assert isinstance(end_lineno, int)").

On Wed, Jan 27, 2021 at 2:36 PM Terry Reedy <tjreedy@udel.edu> wrote:

pyclbr is the stdlib module browser (once just class browser, hence the
name). The doc
https://docs.python.org/3/library/pyclbr.html#module-pyclbr, which I
revised in 2017, documents readline and readline_ex as the public call
interface. The functions return a hierarchical structure that includes
Function and Class instances. (Both subclass pyclbr._Object.) The doc
I revised already omitted signatures for these classes and just listed
the attributes of instances. Just before that listing, I added "Users
are not expected to create instances of these classes."

https://bugs.python.org/issue38307 and
https://github.com/python/cpython/pull/24348
propose to add an end_lineno attribute. Since pyclbr is now, since last
November, based on the ast tree and since the relevant ast nodes have an
end_line attribute, the proposal amounts to copying that attribute,
along with others, instead of ignoring it.

The patch proposes to add 'end_lineno' after existing start 'lineno' in
the _Object, Function, and Class signatures. I prefer doing this,
rather than adding the new parameter at the end of the list, because a)
being the the logical place would make the code easier to read, and b)
new names as the end of the signature, follow optional arguments, would
have to be optional, whereas

My question is whether the omission of signatures and my added sentence
sufficiently defines the signatures of these classes (in particular, the
argument order) as private to approve the patch as is?

--
Terry Jan Reedy
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/SQWNNGY7WADHFGAIQZRIMPPLYJGIV4TZ/
Code of Conduct: http://python.org/psf/codeofconduct/