[Python-ideas] Proposal: Use mypy syntax for function annotations

[Guido van Rossum]

On Mon, Aug 25, 2014 at 4:36 PM, Terry Reedy <tjreedy at udel.edu> wrote:

> On 8/25/2014 11:12 AM, Guido van Rossum wrote:
>
>> On Sun, Aug 24, 2014 at 11:18 PM, Terry Reedy
>>
>
>      I believe co-existence is possible, but the details will depend on
>>     the form type hints take. First, other annotations should be easily
>>     distinguished from type hints. Second, other annotations that would
>>     interfere with the runtime use of __annotations__ should be pulled
>>     out by a decorator and possibly moved to another attribute specific
>>     to the decorator (such as '_deco_name').
>>
>>
>> What exactly do you mean by "other annotations that would interfere with
>> the runtime use of __annotations__"?
>>
>
> I am referring to the current stdlib runtime use of .__annotations__
> directly by inspect.getfullargspec and now inspect.signature and indirectly
> by Idle calltips.
>
> def f(n:[int, 'random non-type info'])->(int, 'more non-type info'): pass
> import inspect as ip
> print(ip.formatargspec(*ip.getfullargspec(f)))
> print(str(ip.signature(f)))
>
> (n: [<class 'int'>, 'random non-type info']) -> (<class 'int'>, 'more
> non-type info')
> (n:[<class 'int'>, 'random non-type info']) -> (<class 'int'>, 'more
> non-type info')
>
> (Idle currently displays the first, will change to the second. The display
> difference is more pronounced (now, at least) for C functions with
> .__text_signature__ from Argument Clinic.)
>
> To me, 'argument specification' and especially 'signature' imply arguments
> names and types, but not other stuff. Certainly, name and type is all that
> is wanted for a tip on how to write a call.  Extra stuff would typically be
> noise in this context -- especially for beginners.
>

I see two possible concerns here -- can you clarify?

(1) If a function is annotated with multiple *categories* of annotations
(e.g. type hints and html form specifiers) you want to change inspect to
only return the type hints.

(2) If a function is annotated for a non-type-hinting category (e.g. only
html form specifiers) you want to change inspect to return nothing.

I hadn't thought of either of these; I was only concerned about making sure
that a static type checker wouldn't be unduly confused by non-type-hinting
annotations. I assume __annotations__ should always return the full
expression found in the syntactic position of the annotation (though
decorators can change this).


>  I can only assume that you are thinking of a situation where you are
>> introspecting some function/method of unknown origin and you are trying
>> to see if it has any annotations, in which case you are going to use
>> them for a locally-defined use (e.g. generate an HTML form -- contrived
>> example).
>>
>> It sounds as if you are worried about being passed a function that in
>> the past would not have any annotations (so you would just generate a
>> default form based on the argument names) but which now has been
>> annotated by a zealous programmer with type hints. And you are worried
>> that those type hints will confuse (perhaps crash) the form-generation
>> code.
>>
>
> I am worried about annotations other than type hints. Compact type hints,
> especially for type-opaque parameter names, should improve the usefulness
> of call tips. Extra noise detracts.
>
> If type hints were standardized so as to be easily recognizable,
> .signature could be given an option to ignore anything else.
>

So I think you are actually not excited about any mechanism to keep other
uses of annotations alive, and you would just as well only have them used
for type hints? (That's fine with me, but there is the backward
compatibility issue, and perhaps legitimate cool alternate uses of
annotations. We still have the choice to allow only one category of
annotations per function.)

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140825/ffe69884/attachment-0001.html>