Thanks for the detailed explanation. Boxing annotations inside modules seem to address my main concern: one could choose to only support its own subset, disregarding the rest. Nice job ! You get my vote :D Best, V. Le dim. 26 mai 2019 à 06:53, Till <till.varoquaux@gmail.com> a écrit :
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 <
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
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
vincent.siles+pyty@gmail.com> wrote: parsing an expression and use some algorithm to detect if the type checker 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?)