(original) (raw)



On 03/19/2013 12:23 AM, Nick Coghlan wrote:
On Mon, Mar 18, 2013 at 11:08 PM, Stefan Behnel  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