
On 10/26/2021 11:19 AM, Chris Angelico 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
On Wed, Oct 27, 2021 at 2:05 AM Eric V. Smith <eric@trueblade.com> wrote: 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