[Python-Dev] signature.object, argument clinic and grouped parameters

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

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.


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

More information about the Python-Dev mailing list