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 <tjre...@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-le...@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/ > -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/64UDFAO7472BVQRABDKVXIIDT42RZBKJ/ Code of Conduct: http://python.org/psf/codeofconduct/
