[Python-Dev] Rough idea for adding introspection information for builtins

[Larry Hastings]

On 03/19/2013 12:23 AM, Nick Coghlan wrote:
> On Mon, Mar 18, 2013 at 11:08 PM, Stefan Behnel <stefan_ml at behnel.de> wrote:
>>> My first idea for implementation: add a "def x" to the front and ": pass"
>>> to the end
>> Why not require it to be there already? Maybe more like
>>
>>      def foo(arg, b=3, *, kwonly='a'):
>>           ...
>>
>> (i.e. using Ellipsis instead of pass, so that it's clear that it's not an
>> empty function but one the implementation of which is hidden)
> I like this notion. The groups notation and '/' will still cause the
> parser to choke and require special handling, but OTOH, they have
> deliberately been chosen as potentially acceptable notations for
> providing the same features in actual Python function declarations.

I don't see the benefit of including the "def foo" and ":\n ...".  The 
name doesn't help; inspect.Signature pointedly does /not/ contain the 
name of the function, so it's irrelevant to this purpose.  And why have 
unnecessary boilerplate?

And if I can go one further: what we're talking about is essentially a 
textual representation of a Signature object.  I assert that the stuff 
inside the parentheses, and the return annotation, *is* the signature.  
The name isn't part of the signature, and the colon and what lies 
afterwards is definitely not part of its signature.  So I think it's 
entirely appropriate, and a happy coincidence, that it happens to 
reflect the minimum amount of text you need to communicate the signature.


>> IMHO, if there is no straight forward way currently to convert a function
>> header from a code blob into a Signature object in Python code, preferably
>> using the ast module (either explicitly or implicitly through inspect.py),
>> then that's a bug.
> The complexity here is that Larry would like to limit the annotations
> to compatibility with ast.literal_eval. If we drop that restriction,
> then the inspect module could handle the task directly. Given the
> complexity of implementing it, I believe the restriction needs more
> justification than is currently included in the PEP.

I concede that it's totally unjustified in the PEP.  It's more playing a 
hunch at the moment, a combination of YAGNI and that it'd be hard to put 
the genie back in the bottle if we let people use arbitrary values.

Let me restate what we're talking about.  We're debating what types of 
data should be permissible to use for a datum that so far is not only 
unused, but is /required/ to be unused.  PEP 8 states " The Python 
standard library will not use function annotations".  I don't know who 
among us has any experience using function annotations--or, at least, 
for their intended purpose.  It's hard to debate what are reasonable vs 
unreasonable restrictions on data we might be permitted to specify in 
the future for uses we don't know about.  Restricting it to Python's 
rich set of safe literal values seems entirely reasonable; if we get 
there and need to relax the restriction, we can do so there.

Also, you and I discussed this evening whether there was a credible 
attack vector here.  I figured, if you're running an untrustworthy 
extension, it's already game over.  You suggested that a miscreant could 
easily edit static data on a trusted shared library without having to 
recompile it to achieve their naughtiness.  I'm not sure I necessarily 
buy it, I just wanted to point out you were the one making the case for 
restricting it to ast.literal_eval.  ;-)


>> Is sounds simpler to me to just make it a Python syntax feature. Or at
>> least an optional one, supported by the ast module with a dedicated
>> compiler flag.
> Agreed. Guido had previously decided "not worth the hassle", but this
> may be enough to make him change his mind. Also, Larry's "simple"
> solution here isn't enough, since it doesn't handle optional groups
> correctly.

I certainly don't agree that "remove the slash and reparse" is more 
complicated than "add a new parameter metaphor to the Python language".  
Adding support for it may be worth doing--don't ask me, I'm still 
nursing my "positional-only arguments are part of Python and forever 
will be" Kool-aid.  I'm just dealing with cold harsh reality as I 
understand it.

As for handling optional argument groups, my gut feeling is that we're 
better off not leaking it out of Argument Clinic--don't expose it in 
this string we're talking about, and don't add support for it in the 
inspect.Parameter object.  I'm not going to debate range(), the syntax 
of which predates one of our release managers.  But I suggest option 
groups are simply a misfeature of the curses module. There are some 
other possible uses in builtins (I forgot to dig those out this evening) 
but so far we're talking adding complexity to an array of technologies 
(this representation, the parser, the Parameter object) to support a 
handful of uses of something we shouldn't have done in the first place, 
for consumers who I think won't care and won't appreciate the added 
conceptual complexity.


//arry/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20130319/b6f41ee4/attachment.html>