On 10/26/2021 11:19 AM, Chris Angelico wrote:
On Wed, Oct 27, 2021 at 2:05 AM Eric V. Smith <e...@trueblade.com> wrote:
Among my objections to this proposal is introspection: how would that
work? The PEP mentions that the text of the expression would be
available for introspection, but that doesn't seem very useful.
Doesn't it? It would certainly be useful in help().
Yes, help() should be accurate. I was referring to programmatic
introspection with the inspect module.
At the very least, the PEP needs to talk about inspect.Signature
objects, and how they would support these late-bound function arguments.
And in particular, how would you create a Signature object that
represents a function with such arguments? What would the default values
look like? I think Dave Beazley has a talk somewhere where he
dynamically creates objects that implement specific Signatures, I'll try
to dig it up and produce an example. For me, it's a show-stopper if you
can't support this with late-bound arguments.
That's a very good point. I suspect that what will happen is that
these args will simply be omitted. It's the only way to ensure that
the values are calculated correctly. But I don't (yet) know enough of
the details of inspect.Signature to say for sure.
Okay. I look forward to your thoughts. Omitting late-bound arguments or
defaults would not be acceptable. You may or may not recall that a big
reason for the removal of "tuple parameter unpacking" in PEP 3113 was
that they couldn't be supported by the inspect module. Quoting that PEP:
"Python has very powerful introspection capabilities. These extend to
function signatures. There are no hidden details as to what a function's
call signature is."
(Aside: I loved tuple parameter unpacking, and used it all the time! I
was sad to see them go, but I agreed with PEP 3113.)
And also the "No Loss of Abilities If Removed" section sort of applies
to late-bound function arguments: there's nothing proposed that can't
currently be done in existing Python. I'll grant you that they might
(might!) be more newbie-friendly, but I think the bar is high for
proposals that make existing things doable in a different way, as
opposed to proposals that add new expressiveness to the language.
Eric
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/PCRF3W3II5RMIR2YH77RT3A4XXVTSR32/
Code of Conduct: http://python.org/psf/codeofconduct/
