On 1/29/2021 8:57 PM, Guido van Rossum wrote:
On Fri, Jan 29, 2021 at 5:39 PM Terry Reedy <[email protected]
<mailto:[email protected]>> wrote:
Guido, thank you for the helpful discussion. I now think that we
should
just add 'end_lineno=None' at the end of the Function/Class __init__
signatures. pyclbr makes one call to each to contruct the tree it
returns, and the test functions make another call to each.
If those are the only two calls to each, it hardly matters what they
look like. If there are non-stdlib calls, it is not worth breaking
them. And others might well localize their Function/Class calls within
wrappers similar to _nest_function() and _nest_class().
Okay, I wasn't quite ready to recommend this, but I agree that that's
the most compatible solution. (Put a `*` before the optional arg so it
must be specified as a keyword.)
I presume you mean immediately before 'end_lineno', as putting it before
all optional params would break positional passing.
A more important pyclbr issue, I think, is that readline and
readline_ex
return a 'half node', a dict of children, instead of a Module node. It
is a nuisance, such as when constructing IDLE's module browser
tree. It
is the same as if ast_parse were to return the body list of ast.Module
instead of ast.Module itself. A readmodule() function could return a
proper tree with a root Module node, with attributes file, name, lineno
(1), end_lineno, and children.
Sounds good. Thanks for caring about this very old module! (I am not
100% sure of its origins but I think it may have been written in
Python's earliest years by one of my office mates, Sjoerd Mullender.)
Adding a new API would be an opportunity to 'do it right'. The test of
it being an improvement is if it allows simplification of the module
browser code.
--
Terry Jan Reedy
_______________________________________________
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/KAQBTNC5R5IHHXKPUIVMKAPFTNIHE7BK/
Code of Conduct: http://python.org/psf/codeofconduct/