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

[Terry Reedy]

On 8/25/2014 7:58 PM, Guido van Rossum wrote:
 > On Mon, Aug 25, 2014 at 4:36 PM, Terry Reedy <tjreedy at udel.edu
 > <mailto:tjreedy at udel.edu>> wrote:

 >     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.

Both are covered by "I would either like non-type-hinting annotations 
moved elsewhere by decorators (my older idea) *or* I would like 
inspect.signature to at least optionally ignore them (today's idea). The 
latter is more dependable since we control the inspect functions.

I an not too worried that anyone would use the blessed type-hint syntax 
for something completely different. On the other hand, I can imagine 
that there might someday be more that one annotation system in general use.

 > 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.

If, for instance, everything in typing or produced by the function is a 
subclass of BaseTyping or an instance of MetaTyping, then post-compile 
typing objects would be easy to distinguish.  Source annotations are a 
harder problem.

 >I assume __annotations__ should always
 > return the full expression found in the syntactic position of the
 > annotation

I think that should continue.

 > (though decorators can change this).

Because .__annotations__ is a regular dict.

annotation syntax in code --compiler>>
initial .__annotation__ dict --decorators>>
exposed .__annotation__  dict + any other attributes added.

 >     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,

I want there to be such a mechanism even though it is does not 'excite' me .

Just as you are focused on type hints for static hints, I, *as an Idle 
maintainer* who just happens to have spent considerable time on the call 
tip feature, am focused on type hints for dynamic documentation.

 > and you would just as well only have them used for type hints?

Too strong.

 > (That's fine with me, but there is the backward compatibility issue,

I said in my first response that I don't think we should break code. 
This is me speaking a as core developer and community member. I do want 
multiple ramifications of annotation use considered, including run-time use.

 > and perhaps legitimate cool alternate uses of annotations.

Most experiments do not amount to much, but a few, such as the metaclass 
hack, certainly have. Python should continue to allow experiments.

 > We still have the choice to allow only one category of
 > annotations per function.)

This seems dubious to me. If strings, tuples, or dicts are allowed as 
annotations, it seems to me that they can be used to combine annotations.
-- 
Terry Jan Reedy