<p dir="ltr"><br>
On 21 Jan 2014 09:26, "Larry Hastings" <<a href="mailto:larry@hastings.org">larry@hastings.org</a>> wrote:<br>
><br>
><br>
><br>
> On 01/20/2014 04:59 AM, Nick Coghlan wrote:<br>
>><br>
>> When I wrote that, I was thinking we had made<br>
>> inspect.Signature.__repr__ produce a nice string format, but then I<br>
>> noticed in the REPL today that we never got around to doing that - I<br>
>> think because we didn't know how to handle positional-only arguments,<br>
>> which already can't be expressed as Python syntax. (I haven't checked<br>
>> if we have an RFE filed anywhere)<br>
><br>
><br>
> 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.)<br>

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

<p dir="ltr">Positional only is fine - PEP 362 already handles those.</p>
<p dir="ltr">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.</p>
<p dir="ltr">> 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".</p>
<p dir="ltr">No. I am saying there *are* signatures that the *inspect module* cannot express in its public API.</p>
<p dir="ltr">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.</p>
<p dir="ltr">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.</p>

<p dir="ltr">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?</p>

<p dir="ltr">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.</p>

<p dir="ltr">Regards,<br>
Nick.</p>