Hi Vincent,
Let me explain the reasoning behind the current design.

Roughly speaking annotations will be consumed either:
- At runtime, using `get_type_hints`. In this case the main challenge
is to write a function that explores the type graph (once recursive
types are more common it'll be a graph I guess...). It's pretty easy
to make all the annotations you cared about be instances of classes
you own (e.g.: Annotated[T, pytorch.MyAnnotation(X)]) and that
provides a clean namespacing scheme.

    def get_pytorch_annotatiions(n):
        if not isinstance(n, typing.Annotated):
            return []
        return [a for a in x.__metadata__ if isinstance(x, pytorch.Annotation)]

 The spec is flexible enough to allow other forms of annotations:

     Annotated[T, ("pytorch", X)]

- Statically. Now this is the hard case and I could see potential
consumers not being happy about having to resolve annotations
statically; after all it can be reduced to the halting problem. We
already have this problem for types since they are first class values.
In practice most type checkers already have to handle forward
references, name aliasing... Owners of those tools get to decide what
subset of python they will handle (and how they want to handle the
rest). For instance you could design a simple checker that only
considers annotations that are tuples and doesn't handle aliasing.

Our current design is very lax and it doesn't really offer a good way
to restrict which context annotations are used in. E.g.:

     Annotated[str, range_checker.ValueRange(1, 10)]

I'm a bit worried that anything more structured would end up making
the annotations unsuitable for some use case we haven't thought of
yet.

Sorry if that was a bit pedantic, let me know if there's anything that
needs clarification (or needs to be changed in the spec).

Till

On Sat, May 25, 2019 at 8:25 PM Guido van Rossum <guido@python.org> wrote:
>
> Sounds like you're brainstorming. I'll leave it to Till or one of the co-authors to respond with an argument why they prefer the current spec.
>
> On Sat, May 25, 2019 at 4:38 PM Vincent Siles <vincent.siles+pyty@gmail.com> wrote:
>>
>> I can't think about something precise at the moment, but it seems simpler to have something like "pytorch" or "panda" in the annotations to
>> explain in which context this annotation should be used, rather than parsing an expression and use some algorithm to detect if the type checker
>> knows how to make sense of it.
>>
>> Another situation that comes to mind would be a library that is used in a context where the annotation is needed and in another where it is useless.
>> Not a big problem, but allowing the type checker to disregard an annotation even if it knows how to parse it might be an interesting feature.
>>
>> Le sam. 25 mai 2019 à 16:42, Guido van Rossum <guido@python.org> a écrit :
>>>
>>> On Sat, May 25, 2019 at 12:07 AM Vincent Siles <vincent.siles+pyty@gmail.com> wrote:
>>>>
>>>> If my understanding is correct, a type-checker will have to parse the whole annotation payload to decide if it supports it or not.
>>>> That's seems a bit too complicated, doesn't it ? Shouldn't we add a label (like `Annotated[T, 'feature name', X]`, with type alias to shorten the whole thing if need be) to make this decision easier ?
>>>
>>>
>>> But ISTM the type-checker has to parse the whole payload regardless. Can you elaborate an example of an annotation payload that would be a burden for the type-checker to parse?
>>>
>>> --
>>> --Guido van Rossum (python.org/~guido)
>>> Pronouns: he/him/his (why is my pronoun here?)
>
>
>
> --
> --Guido van Rossum (python.org/~guido)
> Pronouns: he/him/his (why is my pronoun here?)