On 8/25/2014 7:58 PM, Guido van Rossum wrote:

On Mon, Aug 25, 2014 at 4:36 PM, Terry Reedy <tjreedy@udel.edu <mailto:tjreedy@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