[Python-Dev] signature.object, argument clinic and grouped parameters (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Mon Jan 20 13:59:38 CET 2014

On 20 January 2014 20:16, Larry Hastings <larry at hastings.org> wrote:

On 01/19/2014 08:30 PM, Nick Coghlan wrote: Guido, Larry and I thrashed out the required semantics for parameter groups at PyCon US last year (and I believe the argument clinic PEP describes those accurately). They're mainly needed to represent oddball signatures like range() and slice(). However, I'm inclined to say that the affected functions should simply not support introspection until Python 3.5. It's not just a matter of the data model, there's also the matter of defining the string representation. Au contraire!, says the man writing patches.

When I wrote that, I was thinking we had made inspect.Signature.repr produce a nice string format, but then I noticed in the REPL today that we never got around to doing that - I think because we didn't know how to handle positional-only arguments, which already can't be expressed as Python syntax. (I haven't checked if we have an RFE filed anywhere)

However, while I know you're keen to finally make introspection work for all C level callables in 3.4, even the ones with signatures that can't be expressed as Python function signatures, I'd like to strongly encourage you to hold off on that last part until Python 3.5.

We're already in beta, we're already introducing a lot of code churn to get the C level callables that can have their signatures expressed as Python syntax converted, so where's the harm to users in saying that C level callables with non-Python signatures still don't support introspection in Python 3.4? Almost no C level callables support programmatic introspection in Python 3.3, so even what inspect.signature will already provide in beta 3 is a big step forward.

While the text string used to communicate between Argument Clinic and inspect.signature will be private, the representation on inspect.Signature objects will be a new public API. As the discussions between you, me and Yury show, I don't think there's an immediately obvious best answer of how to do that. Your suggestion of just adding the group numbers to the Parameter objects would work, but it's not very Pythonic - we have container types that support nesting, which seems like a more natural structure for indicating parameter groups at the Python level. Essentially, the group number proposal feels like the kind of low level interface returned by getfullargspec(), not the kind of high level interface defined for inspect.Signature in PEP 362. It's going to take a while to come up with a public API for this aspect of C level signatures that feels right to at least you, me and Yury, and the beta period really isn't the right time to be doing that.

If other changes like the binary interpolation proposals and adding the PEP 451 based target attributes to runpy can wait until Python 3.5 due to feature freeze, then I think adding full C level signature support to inspect.Signature can also wait.

That way, you can resurrect PEP 457, recast it as proposing an output format for inspect.Signature.repr(), add an inspect.Signature.fromstr() API that can use it to create a signature object from text_signature attributes (rather than relying on ast.parse), add the optional group support and do it right, rather than trying to squeeze it in as a new public API during the beta period, which may lock us in to supporting an introspection API we later regret.

Regards, Nick.

-- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia

More information about the Python-Dev mailing list