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

[Nick Coghlan]

On 21 Jan 2014 09:26, "Larry Hastings" <larry at hastings.org> wrote:
>
>
>
> On 01/20/2014 04:59 AM, Nick Coghlan wrote:
>>
>> 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)
>
>
> I don't know what you had intended to do, but right now inspect.Signature
inherits the standard repl from object.  inspect.Signature.__str__ produces
something that looks like a Python function signature, starting and ending
with parentheses.  (For those of you unfamiliar with inspect.Signature: A
signature is agnostic about the name of the function.  So it doesn't
include the name.)
>
>
>
>> 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.
>
>
> If we hold off on all of this until 3.5, the signatures for most builtins
will be wrong in 3.4, because most builtins take positional-only
parameters.  I had higher hopes for Python 3.4 than that.  To be honest I'd
rather not have the feature at all than have it be wrong most of the time.

Positional only is fine - PEP 362 already handles those.

It only doesn't handle things like range(), and those callables should
continue to not support introspection at all rather than reporting an
incorrect signature.

> I think it's fair to summarize your argument as "there could be monsters
lurking in CPython with signatures that can't be expressed in PEP 457
syntax".

No. I am saying there *are* signatures that the *inspect module* cannot
express in its public API.

You already *know* that, since you are proposing to add a new feature
(group support) to inspect.Signature late in the beta cycle in order to
handle those cases.

I am saying that's a gross violation of our established processes. The
argument clinic conversions can be defended as internal implementation
details. A new public feature in the inspect module cannot.

Please turn the question around and look at it with your release manager
hat on rather than your creator of Argument Clinic hat: if I came to you
and said I wanted to add a new public API to the inspect module after the
second beta release, what would you say? Can you honestly say that if
*someone else* was proposing the inclusion of a new public API this late in
the release cycle, you would say yes?

If I can wait until 3.5 to add PEP 451 "target" parameters to runpy because
I was too busy to land that before feature freeze, and Eric can wait to
fully support PEP 451 for builtin and extension modules, and Ethan can wait
to restore binary interpolation, and Antoine can wait a full release cycle
between adding qualified names in 3.3 and actually seeing them used in an
updated pickle protocol in 3.4, there's no good reason to rush adding
introspection support for oddball legacy signatures to the inspect module.

Regards,
Nick.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20140121/eb710d34/attachment.html>