PEP 593: Flexible function and variable annotations
Hi, We've just landed pep-593 (https://www.python.org/dev/peps/pep-0593/); it proposes adding support to embed metadata inside type annotations. I'm looking forward to hearing people's opinion. Best, Till
I just wanted to mention that I really like the idea in this PEP. And even if it will not make it to Python 3.8 (the schedule is tight), I would propose to add it to `typing_extensions` so that we can experiment with it, -- Ivan On Mon, 20 May 2019 at 20:18, Till <till.varoquaux@gmail.com> wrote:
Hi,
We've just landed pep-593 (https://www.python.org/dev/peps/pep-0593/); it proposes adding support to embed metadata inside type annotations. I'm looking forward to hearing people's opinion.
Best, Till _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/
Overall I like the PEP and examples. One more thing you might consider writing an example for: cython. It *should* be feasible for a future cython to understand typing.Annotated based annotations that contain the cython type so that cython code can be both pep484 type checked _and_ cython compiled down to faster code due to the cython c types specified via annotation. Perhaps reach out to the Cython project and see what they think? I don't anyone to love the potential extra verbosity that comes when you have annotations for multiple purposes at once, but you do already cover that in the PEP in what seems like a reasonable manner. -gps On Tue, May 21, 2019 at 3:51 PM Ivan Levkivskyi <levkivskyi@gmail.com> wrote:
I just wanted to mention that I really like the idea in this PEP. And even if it will not make it to Python 3.8 (the schedule is tight), I would propose to add it to `typing_extensions` so that we can experiment with it,
-- Ivan
On Mon, 20 May 2019 at 20:18, Till <till.varoquaux@gmail.com> wrote:
Hi,
We've just landed pep-593 (https://www.python.org/dev/peps/pep-0593/); it proposes adding support to embed metadata inside type annotations. I'm looking forward to hearing people's opinion.
Best, Till _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/
_______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/
On 20 May 2019, at 21:18, Till <till.varoquaux@gmail.com> wrote:
Hi,
We've just landed pep-593 (https://www.python.org/dev/peps/pep-0593/); it proposes adding support to embed metadata inside type annotations. I'm looking forward to hearing people's opinion.
Best, Till _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/
As mentioned in https://github.com/python/typing/issues/600 I’m a big fan of this proposal. Is there a chance an experimental implementation emerges before this PEP is accepted? If there was I’d really like to implement Injector integration to see if it does all I expect it to. Best, Jakub
I like to where this is going. Plus one from me. I assume the main users of this annotated metadata will be typing checker(s) plugins? Do we provide any unrolling guarantees with type aliases? UnsignedShort = Annotated[int, struct2.ctype('H')] class Student(struct2.Packed): name: UnsignedShort Do we get? get_type_hints(Student, include_extras=True) == { 'name': UnsignedShort} or get_type_hints(Student, include_extras=True) == { 'name': Annotated[int, struct2.ctype('H')]} I would propose to make it explicit what's the expected behaviour here (so processing code does not need to handle both cases). I'd guess the easiest and safest is to go with the { 'name': UnsignedShort} form always. On Wed, May 22, 2019 at 9:06 AM Jakub Stasiak <jakub@stasiak.at> wrote:
On 20 May 2019, at 21:18, Till <till.varoquaux@gmail.com> wrote:
Hi,
We've just landed pep-593 (https://www.python.org/dev/peps/pep-0593/); it proposes adding support to embed metadata inside type annotations. I'm looking forward to hearing people's opinion.
Best, Till _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/
As mentioned in https://github.com/python/typing/issues/600 I’m a big fan of this proposal. Is there a chance an experimental implementation emerges before this PEP is accepted? If there was I’d really like to implement Injector integration to see if it does all I expect it to.
Best, Jakub _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/
On 22 May 2019, at 11:35, Bernat Gabor <gaborjbernat@gmail.com> wrote:
I like to where this is going. Plus one from me. I assume the main users of this annotated metadata will be typing checker(s) plugins? (…)
Not necessarily. Mentioned in the PEP is a possible struct module runtime integration. I co-maintain Injector[1], a dependency injection framework, and It could also use the extra metadata at runtime. Currently one declares a constructor mixing injectable and non-injectable parameters like this: @inject @noninjectable(‘value’) def __init__(self, service: Service, value: Value): This PEP would make the following possible while reducing repetition somewhat and improving editor integration: @inject def __init__(self, service: Service, value: Assisted[Value]): Or even (remains to be seen which is better, maybe both could coexist): def __init__(self, service: Inject[Service], value: Value): (Assisted and Inject are hypothetical generic aliases). Best, Jakub [1] https://github.com/alecthomas/injector
If the implementation lands in typing_extensions *now*, maybe it's reasonable to review that and copy it into the stdlib as soon as the PEP has been accepted. We could make that work. Don't wait implementing until the PEP is accepted though! On Wed, May 22, 2019 at 5:03 AM Jakub Stasiak <jakub@stasiak.at> wrote:
On 22 May 2019, at 11:35, Bernat Gabor <gaborjbernat@gmail.com> wrote:
I like to where this is going. Plus one from me. I assume the main users
of this annotated metadata will be typing checker(s) plugins?
(…)
Not necessarily. Mentioned in the PEP is a possible struct module runtime integration. I co-maintain Injector[1], a dependency injection framework, and It could also use the extra metadata at runtime. Currently one declares a constructor mixing injectable and non-injectable parameters like this:
@inject @noninjectable(‘value’) def __init__(self, service: Service, value: Value):
This PEP would make the following possible while reducing repetition somewhat and improving editor integration:
@inject def __init__(self, service: Service, value: Assisted[Value]):
Or even (remains to be seen which is better, maybe both could coexist):
def __init__(self, service: Inject[Service], value: Value):
(Assisted and Inject are hypothetical generic aliases).
Best, Jakub
[1] https://github.com/alecthomas/injector
_______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/
-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him/his **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
On Wed, 22 May 2019 at 15:31, Guido van Rossum <guido@python.org> wrote:
If the implementation lands in typing_extensions *now*, maybe it's reasonable to review that and copy it into the stdlib as soon as the PEP has been accepted. We could make that work. Don't wait implementing until the PEP is accepted though!
This is a good idea! Having a reference implementation would simplify the process. Till, please go ahead and make a PR to typing_extensions (it still lives in python/typing repo). -- Ivan
Happy to see positive reactions, I'll get started on the implementation in typing-extensions. Bernat; I'm not sure I follow your question:
Do we get?
get_type_hints(Student, include_extras=True) == { 'name': UnsignedShort}
or
get_type_hints(Student, include_extras=True) == { 'name': Annotated[int, struct2.ctype('H')]}
UnsignedShort == Annotated[int, struct2.ctype('H') so both these equalities should hold. Does that make sense? Till
I was more enquiring what the actual implementation will return, and if it's worth deciding by one form or other; or both are allowed and determined as an implementation detail. Assume I want to do some kind of processing based on this meta-data, as a consumer of get_type_hints which form should I expect, or both are valid and I need to handle both cases? On Wed, May 22, 2019 at 4:01 PM Till <till.varoquaux@gmail.com> wrote:
Happy to see positive reactions, I'll get started on the implementation in typing-extensions.
Bernat; I'm not sure I follow your question:
Do we get?
get_type_hints(Student, include_extras=True) == { 'name': UnsignedShort}
or
get_type_hints(Student, include_extras=True) == { 'name': Annotated[int, struct2.ctype('H')]}
UnsignedShort == Annotated[int, struct2.ctype('H') so both these equalities should hold. Does that make sense?
Till
Would people object to me implementing this only for `python >= 3.7` in typing_extension? I'm new to that codebase and it seems like this would make it easier to implement (using __class_getitems__...). Otherwise I can aim for a first patch that adds 3.7 and work my way down to older revisions.
If it makes it easier, I'd definitely start with >= 3.7. That will be sufficient as a proof of concept and will provide the baseline to include in the 3.8 stdlib typing.py (if the PEP makes it through quickly enough). But I assume people would want to use this on legacy code as well (several companies I know who are using type checkers have large legacy code bases, for some value of legacy). On Wed, May 22, 2019 at 11:20 AM Till <till.varoquaux@gmail.com> wrote:
Would people object to me implementing this only for `python >= 3.7` in typing_extension? I'm new to that codebase and it seems like this would make it easier to implement (using __class_getitems__...). Otherwise I can aim for a first patch that adds 3.7 and work my way down to older revisions.
-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him/his **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
Hi ! 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 ? Le mer. 22 mai 2019 à 21:11, Guido van Rossum <guido@python.org> a écrit :
If it makes it easier, I'd definitely start with >= 3.7. That will be sufficient as a proof of concept and will provide the baseline to include in the 3.8 stdlib typing.py (if the PEP makes it through quickly enough).
But I assume people would want to use this on legacy code as well (several companies I know who are using type checkers have large legacy code bases, for some value of legacy).
On Wed, May 22, 2019 at 11:20 AM Till <till.varoquaux@gmail.com> wrote:
Would people object to me implementing this only for `python >= 3.7` in typing_extension? I'm new to that codebase and it seems like this would make it easier to implement (using __class_getitems__...). Otherwise I can aim for a first patch that adds 3.7 and work my way down to older revisions.
-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him/his **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/
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?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
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?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
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?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him/his **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
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?)
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?)
Thanks to Ivan and Jakub I was able to land a (python 3.7 and up) implementation in typing_extension. If you get the library directly from GitHub you can try it out and give your feedback. Till On Sun, May 26, 2019, 6:06 AM Vincent Siles <vincent.siles+pyty@gmail.com> wrote:
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
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 annotation payload to decide if it supports it or not. 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?)
On 27 May 2019, at 22:44, Till <till.varoquaux@gmail.com> wrote:
Thanks to Ivan and Jakub I was able to land a (python 3.7 and up) implementation in typing_extension. If you get the library directly from GitHub you can try it out and give your feedback. Till
Happy to help. I just modified Injector locally to use this and everything works as expected – nicely done! One thing that I’m curious about – what’s the recommended way to see if we’re dealing with Annotated-wrapped type or just a type at runtime? This is what I did: from typing_extensions import _Annotated things = get_type_hints(…, include_extras=True) for k, v in things.items(): if isinstance(v, _Annotated): # special logic here Best, Jakub
I didn't implement any good helper function because I couldn't figure out the idiomatic way to traverse type hints at runtime. It would be very easy to add a "get_extras(t: typing.<Type>) -> Tuple[Any, ...]" function. Would that work? On Mon, May 27, 2019 at 10:20 PM Jakub Stasiak <jakub@stasiak.at> wrote:
On 27 May 2019, at 22:44, Till <till.varoquaux@gmail.com> wrote:
Thanks to Ivan and Jakub I was able to land a (python 3.7 and up) implementation in typing_extension. If you get the library directly from GitHub you can try it out and give your feedback. Till
Happy to help. I just modified Injector locally to use this and everything works as expected – nicely done!
One thing that I’m curious about – what’s the recommended way to see if we’re dealing with Annotated-wrapped type or just a type at runtime? This is what I did:
from typing_extensions import _Annotated
things = get_type_hints(…, include_extras=True) for k, v in things.items(): if isinstance(v, _Annotated): # special logic here
Best, Jakub
On Tue, 28 May 2019 at 04:37, Till <till.varoquaux@gmail.com> wrote:
I didn't implement any good helper function because I couldn't figure out the idiomatic way to traverse type hints at runtime. It would be very easy to add a "get_extras(t: typing.<Type>) -> Tuple[Any, ...]" function. Would that work?
This reminds me about something I wanted to do for Python 3.8: there is an idea to add couple public helpers for introspection of typing objects. For example `get_origin()` and `get_args()`. That would essentially just thin public wrappers around private `__origin__`/`__args__` API. With such API one will be able to just write `if get_origin(typ) is Annotated: ...` -- Ivan
On 28 May 2019, at 11:52, Ivan Levkivskyi <levkivskyi@gmail.com> wrote:
On Tue, 28 May 2019 at 04:37, Till <till.varoquaux@gmail.com> wrote: I didn't implement any good helper function because I couldn't figure out the idiomatic way to traverse type hints at runtime. It would be very easy to add a "get_extras(t: typing.<Type>) -> Tuple[Any, ...]" function. Would that work?
This reminds me about something I wanted to do for Python 3.8: there is an idea to add couple public helpers for introspection of typing objects. For example `get_origin()` and `get_args()`. That would essentially just thin public wrappers around private `__origin__`/`__args__` API.
With such API one will be able to just write `if get_origin(typ) is Annotated: ...`
-- Ivan
_______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/
This actually gave me the idea to test x.__origin__ is Annotated instead of isinstance(x, _Annotated) but with the current implementation _Annotated.__origin__ points to the type being annotated, not the Annotated class. I made a dirty typing_extensions pull request[1] that attempts to rectify this but I’m not sure i’ll be able to finish it myself right now. On an unrelated note, something I’ve been wondering about since yesterday – is Annotated supposed to be, in principle, allowed to be used like this? def fun(x: List[Annotated[int, ‘some marker’]]) Best, Jakub [1] https://github.com/python/typing/pull/634
On 28 May 2019, at 14:53, Jakub Stasiak <jakub@stasiak.at> wrote:
On 28 May 2019, at 11:52, Ivan Levkivskyi <levkivskyi@gmail.com> wrote:
On Tue, 28 May 2019 at 04:37, Till <till.varoquaux@gmail.com> wrote: I didn't implement any good helper function because I couldn't figure out the idiomatic way to traverse type hints at runtime. It would be very easy to add a "get_extras(t: typing.<Type>) -> Tuple[Any, ...]" function. Would that work?
This reminds me about something I wanted to do for Python 3.8: there is an idea to add couple public helpers for introspection of typing objects. For example `get_origin()` and `get_args()`. That would essentially just thin public wrappers around private `__origin__`/`__args__` API.
With such API one will be able to just write `if get_origin(typ) is Annotated: ...`
-- Ivan
_______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/
This actually gave me the idea to test
x.__origin__ is Annotated
instead of
isinstance(x, _Annotated)
but with the current implementation _Annotated.__origin__ points to the type being annotated, not the Annotated class. I made a dirty typing_extensions pull request[1] that attempts to rectify this but I’m not sure i’ll be able to finish it myself right now.
On an unrelated note, something I’ve been wondering about since yesterday – is Annotated supposed to be, in principle, allowed to be used like this?
def fun(x: List[Annotated[int, ‘some marker’]])
Best, Jakub
[1] https://github.com/python/typing/pull/634 _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/
PS. Apologies for ignoring your question regarding hypothetical get_extras function Till – I don’t have an opinion on it at the moment, doing things “manually” is fine for my purposes. Jakub
Thanks Jakub, You're right __origin__ should point to `Annotated`. I created a pull request (https://github.com/python/typing/pull/635) that should address that. Also: def fun(x: List[Annotated[int, ‘some marker’]]) is definitely valid. On Tue, May 28, 2019 at 9:01 AM Jakub Stasiak <jakub@stasiak.at> wrote:
On 28 May 2019, at 14:53, Jakub Stasiak <jakub@stasiak.at> wrote:
On 28 May 2019, at 11:52, Ivan Levkivskyi <levkivskyi@gmail.com> wrote:
On Tue, 28 May 2019 at 04:37, Till <till.varoquaux@gmail.com> wrote: I didn't implement any good helper function because I couldn't figure out the idiomatic way to traverse type hints at runtime. It would be very easy to add a "get_extras(t: typing.<Type>) -> Tuple[Any, ...]" function. Would that work?
This reminds me about something I wanted to do for Python 3.8: there is an idea to add couple public helpers for introspection of typing objects. For example `get_origin()` and `get_args()`. That would essentially just thin public wrappers around private `__origin__`/`__args__` API.
With such API one will be able to just write `if get_origin(typ) is Annotated: ...`
-- Ivan
_______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/
This actually gave me the idea to test
x.__origin__ is Annotated
instead of
isinstance(x, _Annotated)
but with the current implementation _Annotated.__origin__ points to the type being annotated, not the Annotated class. I made a dirty typing_extensions pull request[1] that attempts to rectify this but I’m not sure i’ll be able to finish it myself right now.
On an unrelated note, something I’ve been wondering about since yesterday – is Annotated supposed to be, in principle, allowed to be used like this?
def fun(x: List[Annotated[int, ‘some marker’]])
Best, Jakub
[1] https://github.com/python/typing/pull/634 _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/
PS. Apologies for ignoring your question regarding hypothetical get_extras function Till – I don’t have an opinion on it at the moment, doing things “manually” is fine for my purposes.
Jakub
On 28 May 2019, at 17:58, Till <till.varoquaux@gmail.com> wrote:
Thanks Jakub, You're right __origin__ should point to `Annotated`. I created a pull request (https://github.com/python/typing/pull/635) that should address that. Also:
def fun(x: List[Annotated[int, ‘some marker’]])
is definitely valid.
On Tue, May 28, 2019 at 9:01 AM Jakub Stasiak <jakub@stasiak.at> wrote:
On 28 May 2019, at 14:53, Jakub Stasiak <jakub@stasiak.at> wrote:
On 28 May 2019, at 11:52, Ivan Levkivskyi <levkivskyi@gmail.com> wrote:
On Tue, 28 May 2019 at 04:37, Till <till.varoquaux@gmail.com> wrote: I didn't implement any good helper function because I couldn't figure out the idiomatic way to traverse type hints at runtime. It would be very easy to add a "get_extras(t: typing.<Type>) -> Tuple[Any, ...]" function. Would that work?
This reminds me about something I wanted to do for Python 3.8: there is an idea to add couple public helpers for introspection of typing objects. For example `get_origin()` and `get_args()`. That would essentially just thin public wrappers around private `__origin__`/`__args__` API.
With such API one will be able to just write `if get_origin(typ) is Annotated: ...`
-- Ivan
_______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/
This actually gave me the idea to test
x.__origin__ is Annotated
instead of
isinstance(x, _Annotated)
but with the current implementation _Annotated.__origin__ points to the type being annotated, not the Annotated class. I made a dirty typing_extensions pull request[1] that attempts to rectify this but I’m not sure i’ll be able to finish it myself right now.
On an unrelated note, something I’ve been wondering about since yesterday – is Annotated supposed to be, in principle, allowed to be used like this?
def fun(x: List[Annotated[int, ‘some marker’]])
Best, Jakub
[1] https://github.com/python/typing/pull/634 _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/
PS. Apologies for ignoring your question regarding hypothetical get_extras function Till – I don’t have an opinion on it at the moment, doing things “manually” is fine for my purposes.
Jakub
Cool, the code from your pull request works for me. I don’t think I have any other concernes or questions. Jakub
Just a friendly reminder that the window to get this in to 3.8 is closing. The implementation in typing_extensions is pretty simple; upstreaming it will be easy. Also on a personal level: I'm in between big projects at work, now is a good time for me to work on it. The backport (to python versions prior to pep_560) is proving a bit more challenging and I doubt we'll be able to get all the functionalities. I'm still trying to figure out the best way to proceed. Best, Till On Tue, May 28, 2019 at 12:24 PM Jakub Stasiak <jakub@stasiak.at> wrote:
On 28 May 2019, at 17:58, Till <till.varoquaux@gmail.com> wrote:
Thanks Jakub, You're right __origin__ should point to `Annotated`. I created a pull request (https://github.com/python/typing/pull/635) that should address that. Also:
def fun(x: List[Annotated[int, ‘some marker’]])
is definitely valid.
On Tue, May 28, 2019 at 9:01 AM Jakub Stasiak <jakub@stasiak.at> wrote:
On 28 May 2019, at 14:53, Jakub Stasiak <jakub@stasiak.at> wrote:
On 28 May 2019, at 11:52, Ivan Levkivskyi <levkivskyi@gmail.com>
On Tue, 28 May 2019 at 04:37, Till <till.varoquaux@gmail.com> wrote: I didn't implement any good helper function because I couldn't figure out the idiomatic way to traverse type hints at runtime. It would be very easy to add a "get_extras(t: typing.<Type>) -> Tuple[Any, ...]" function. Would that work?
This reminds me about something I wanted to do for Python 3.8: there
is an idea to add couple public helpers for introspection of typing objects.
For example `get_origin()` and `get_args()`. That would essentially just thin public wrappers around private `__origin__`/`__args__` API.
With such API one will be able to just write `if get_origin(typ) is Annotated: ...`
-- Ivan
_______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/
This actually gave me the idea to test
x.__origin__ is Annotated
instead of
isinstance(x, _Annotated)
but with the current implementation _Annotated.__origin__ points to
On an unrelated note, something I’ve been wondering about since
yesterday – is Annotated supposed to be, in principle, allowed to be used
wrote: the type being annotated, not the Annotated class. I made a dirty typing_extensions pull request[1] that attempts to rectify this but I’m not sure i’ll be able to finish it myself right now. like this?
def fun(x: List[Annotated[int, ‘some marker’]])
Best, Jakub
[1] https://github.com/python/typing/pull/634 _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/
PS. Apologies for ignoring your question regarding hypothetical get_extras function Till – I don’t have an opinion on it at the moment, doing things “manually” is fine for my purposes.
Jakub
Cool, the code from your pull request works for me. I don’t think I have any other concernes or questions.
Jakub
I'm sorry, but realistically this is not going to make it into 3.8. Fortunately it should be possible to make the version in typing_extensions.py support all Python versions (including 2.7). On Wed, May 29, 2019 at 2:14 PM Till <till.varoquaux@gmail.com> wrote:
Just a friendly reminder that the window to get this in to 3.8 is closing. The implementation in typing_extensions is pretty simple; upstreaming it will be easy. Also on a personal level: I'm in between big projects at work, now is a good time for me to work on it.
The backport (to python versions prior to pep_560) is proving a bit more challenging and I doubt we'll be able to get all the functionalities. I'm still trying to figure out the best way to proceed.
Best, Till
On Tue, May 28, 2019 at 12:24 PM Jakub Stasiak <jakub@stasiak.at> wrote:
On 28 May 2019, at 17:58, Till <till.varoquaux@gmail.com> wrote:
Thanks Jakub, You're right __origin__ should point to `Annotated`. I created a pull request (https://github.com/python/typing/pull/635) that should address that. Also:
def fun(x: List[Annotated[int, ‘some marker’]])
is definitely valid.
On Tue, May 28, 2019 at 9:01 AM Jakub Stasiak <jakub@stasiak.at> wrote:
On 28 May 2019, at 14:53, Jakub Stasiak <jakub@stasiak.at> wrote:
On 28 May 2019, at 11:52, Ivan Levkivskyi <levkivskyi@gmail.com>
On Tue, 28 May 2019 at 04:37, Till <till.varoquaux@gmail.com> wrote: I didn't implement any good helper function because I couldn't figure out the idiomatic way to traverse type hints at runtime. It would be very easy to add a "get_extras(t: typing.<Type>) -> Tuple[Any, ...]" function. Would that work?
This reminds me about something I wanted to do for Python 3.8: there
is an idea to add couple public helpers for introspection of typing objects.
For example `get_origin()` and `get_args()`. That would essentially just thin public wrappers around private `__origin__`/`__args__` API.
With such API one will be able to just write `if get_origin(typ) is Annotated: ...`
-- Ivan
_______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/
This actually gave me the idea to test
x.__origin__ is Annotated
instead of
isinstance(x, _Annotated)
but with the current implementation _Annotated.__origin__ points to
On an unrelated note, something I’ve been wondering about since
yesterday – is Annotated supposed to be, in principle, allowed to be used
wrote: the type being annotated, not the Annotated class. I made a dirty typing_extensions pull request[1] that attempts to rectify this but I’m not sure i’ll be able to finish it myself right now. like this?
def fun(x: List[Annotated[int, ‘some marker’]])
Best, Jakub
[1] https://github.com/python/typing/pull/634 _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/
PS. Apologies for ignoring your question regarding hypothetical get_extras function Till – I don’t have an opinion on it at the moment, doing things “manually” is fine for my purposes.
Jakub
Cool, the code from your pull request works for me. I don’t think I have any other concernes or questions.
Jakub
-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him/his **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
I understand, this makes a lot of sense. On the plus side: it'll give us plenty of time to nail all the details before 3.9. On Wed, May 29, 2019 at 5:16 PM Guido van Rossum <guido@python.org> wrote:
I'm sorry, but realistically this is not going to make it into 3.8. Fortunately it should be possible to make the version in typing_extensions.py support all Python versions (including 2.7).
On Wed, May 29, 2019 at 2:14 PM Till <till.varoquaux@gmail.com> wrote:
Just a friendly reminder that the window to get this in to 3.8 is closing. The implementation in typing_extensions is pretty simple; upstreaming it will be easy. Also on a personal level: I'm in between big projects at work, now is a good time for me to work on it.
The backport (to python versions prior to pep_560) is proving a bit more challenging and I doubt we'll be able to get all the functionalities. I'm still trying to figure out the best way to proceed.
Best, Till
On Tue, May 28, 2019 at 12:24 PM Jakub Stasiak <jakub@stasiak.at> wrote:
On 28 May 2019, at 17:58, Till <till.varoquaux@gmail.com> wrote:
Thanks Jakub, You're right __origin__ should point to `Annotated`. I created a pull request (https://github.com/python/typing/pull/635) that should address that. Also:
def fun(x: List[Annotated[int, ‘some marker’]])
is definitely valid.
On Tue, May 28, 2019 at 9:01 AM Jakub Stasiak <jakub@stasiak.at> wrote:
On 28 May 2019, at 14:53, Jakub Stasiak <jakub@stasiak.at> wrote:
> On 28 May 2019, at 11:52, Ivan Levkivskyi <levkivskyi@gmail.com>
> > On Tue, 28 May 2019 at 04:37, Till <till.varoquaux@gmail.com> wrote: > I didn't implement any good helper function because I couldn't
> out the idiomatic way to traverse type hints at runtime. It would be > very easy to add a "get_extras(t: typing.<Type>) -> Tuple[Any, ...]" > function. Would that work? > > This reminds me about something I wanted to do for Python 3.8:
> For example `get_origin()` and `get_args()`. That would essentially just thin public wrappers around private `__origin__`/`__args__` API. > > With such API one will be able to just write `if get_origin(typ) is Annotated: ...` > > -- > Ivan > > > _______________________________________________ > Typing-sig mailing list -- typing-sig@python.org > To unsubscribe send an email to typing-sig-leave@python.org > https://mail.python.org/mailman3/lists/typing-sig.python.org/
This actually gave me the idea to test
x.__origin__ is Annotated
instead of
isinstance(x, _Annotated)
but with the current implementation _Annotated.__origin__ points to
On an unrelated note, something I’ve been wondering about since
yesterday – is Annotated supposed to be, in principle, allowed to be used
wrote: figure there is an idea to add couple public helpers for introspection of typing objects. the type being annotated, not the Annotated class. I made a dirty typing_extensions pull request[1] that attempts to rectify this but I’m not sure i’ll be able to finish it myself right now. like this?
def fun(x: List[Annotated[int, ‘some marker’]])
Best, Jakub
[1] https://github.com/python/typing/pull/634 _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/
PS. Apologies for ignoring your question regarding hypothetical get_extras function Till – I don’t have an opinion on it at the moment, doing things “manually” is fine for my purposes.
Jakub
Cool, the code from your pull request works for me. I don’t think I have any other concernes or questions.
Jakub
-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him/his **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
On 29 May 2019, at 23:16, Guido van Rossum <guido@python.org> wrote:
I'm sorry, but realistically this is not going to make it into 3.8. Fortunately it should be possible to make the version in typing_extensions.py support all Python versions (including 2.7).
On Wed, May 29, 2019 at 2:14 PM Till <till.varoquaux@gmail.com> wrote: Just a friendly reminder that the window to get this in to 3.8 is closing. The implementation in typing_extensions is pretty simple; upstreaming it will be easy. Also on a personal level: I'm in between big projects at work, now is a good time for me to work on it.
The backport (to python versions prior to pep_560) is proving a bit more challenging and I doubt we'll be able to get all the functionalities. I'm still trying to figure out the best way to proceed.
Best, Till
On Tue, May 28, 2019 at 12:24 PM Jakub Stasiak <jakub@stasiak.at> wrote:
On 28 May 2019, at 17:58, Till <till.varoquaux@gmail.com> wrote:
Thanks Jakub, You're right __origin__ should point to `Annotated`. I created a pull request (https://github.com/python/typing/pull/635) that should address that. Also:
def fun(x: List[Annotated[int, ‘some marker’]])
is definitely valid.
On Tue, May 28, 2019 at 9:01 AM Jakub Stasiak <jakub@stasiak.at> wrote:
On 28 May 2019, at 14:53, Jakub Stasiak <jakub@stasiak.at> wrote:
On 28 May 2019, at 11:52, Ivan Levkivskyi <levkivskyi@gmail.com> wrote:
On Tue, 28 May 2019 at 04:37, Till <till.varoquaux@gmail.com> wrote: I didn't implement any good helper function because I couldn't figure out the idiomatic way to traverse type hints at runtime. It would be very easy to add a "get_extras(t: typing.<Type>) -> Tuple[Any, ...]" function. Would that work?
This reminds me about something I wanted to do for Python 3.8: there is an idea to add couple public helpers for introspection of typing objects. For example `get_origin()` and `get_args()`. That would essentially just thin public wrappers around private `__origin__`/`__args__` API.
With such API one will be able to just write `if get_origin(typ) is Annotated: ...`
-- Ivan
_______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/
This actually gave me the idea to test
x.__origin__ is Annotated
instead of
isinstance(x, _Annotated)
but with the current implementation _Annotated.__origin__ points to the type being annotated, not the Annotated class. I made a dirty typing_extensions pull request[1] that attempts to rectify this but I’m not sure i’ll be able to finish it myself right now.
On an unrelated note, something I’ve been wondering about since yesterday – is Annotated supposed to be, in principle, allowed to be used like this?
def fun(x: List[Annotated[int, ‘some marker’]])
Best, Jakub
[1] https://github.com/python/typing/pull/634 _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/
PS. Apologies for ignoring your question regarding hypothetical get_extras function Till – I don’t have an opinion on it at the moment, doing things “manually” is fine for my purposes.
Jakub
Cool, the code from your pull request works for me. I don’t think I have any other concernes or questions.
Jakub
-- --Guido van Rossum (python.org/~guido) Pronouns: he/him/his (why is my pronoun here?) _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/
What’s the release schedule of typing_extensions anyway? Once the change is on PyPI I’m happy to make use of it in order to gather some real-world feedback. Best, Jakub
On Fri, 31 May 2019 at 13:53, Jakub Stasiak <jakub@stasiak.at> wrote:
What’s the release schedule of typing_extensions anyway? Once the change is on PyPI I’m happy to make use of it in order to gather some real-world feedback.
Typically, releases are tied to Python point releases. But it is not really a _rule_. I think we should make a release at some point in June, since there were no releases since January. -- Ivan
On Tue, 28 May 2019 at 16:58, Till <till.varoquaux@gmail.com> wrote:
Thanks Jakub, You're right __origin__ should point to `Annotated`. I created a pull request (https://github.com/python/typing/pull/635) that should address that.
I actually don't agree with this change. __origin__ is not a public API and we should not make internal implementation (much) more complex to simplify any public use of it. This is precisely the case why `get_origin()` and `get_args()` were just added to `typing` -- to "decouple" private and public introspection APIs. Moreover, I think _AnnotatedAlias is much more similar to _GenericAlias than to special forms like ClassVar, so it makes sense to make it a "thin" subclass of the latter. `get_origin()` and `get_args()` can be adjusted to return `Annotated` and `(int, 'some marker')`. -- Ivan
On 2 Jun 2019, at 02:29, Ivan Levkivskyi <levkivskyi@gmail.com> wrote:
On Tue, 28 May 2019 at 16:58, Till <till.varoquaux@gmail.com> wrote: Thanks Jakub, You're right __origin__ should point to `Annotated`. I created a pull request (https://github.com/python/typing/pull/635) that should address that.
I actually don't agree with this change. __origin__ is not a public API and we should not make internal implementation (much) more complex to simplify any public use of it. This is precisely the case why `get_origin()` and `get_args()` were just added to `typing` -- to "decouple" private and public introspection APIs.
Moreover, I think _AnnotatedAlias is much more similar to _GenericAlias than to special forms like ClassVar, so it makes sense to make it a "thin" subclass of the latter. `get_origin()` and `get_args()` can be adjusted to return `Annotated` and `(int, 'some marker')`.
I imagine it’s too late to change the functions’ names? I believe something like get_generic_type instead of get_origin and get_generic_args instead of get_args would be *slightly* easier to understand for newcomers. Best, Jakub
On Tue, 11 Jun 2019 at 10:38, Jakub Stasiak <jakub@stasiak.at> wrote:
On 2 Jun 2019, at 02:29, Ivan Levkivskyi <levkivskyi@gmail.com> wrote:
On Tue, 28 May 2019 at 16:58, Till <till.varoquaux@gmail.com> wrote: Thanks Jakub, You're right __origin__ should point to `Annotated`. I created a pull request (https://github.com/python/typing/pull/635) that should address that.
I actually don't agree with this change. __origin__ is not a public API and we should not make internal implementation (much) more complex to simplify any public use of it. This is precisely the case why `get_origin()` and `get_args()` were just added to `typing` -- to "decouple" private and public introspection APIs.
Moreover, I think _AnnotatedAlias is much more similar to _GenericAlias than to special forms like ClassVar, so it makes sense to make it a "thin" subclass of the latter. `get_origin()` and `get_args()` can be adjusted to return `Annotated` and `(int, 'some marker')`.
I imagine it’s too late to change the functions’ names? I believe something like get_generic_type instead of get_origin and get_generic_args instead of get_args would be *slightly* easier to understand for newcomers.
Thanks for the idea, but yes, it is technically too late. Second, the exsiting names are already familiar for people who worked with runtime inspection of typing types. Finally, I don't think `get_generic_type(List[int])` returning `list` is totally intuitive. So after all I would leave the names alone. -- Ivan
Let me revive the thread. As a way to verify the design and the implementation I added Annotated-based markers to Injector (I’ve done it quickly before, now I fully tested it and did it right). https://github.com/alecthomas/injector/commit/d50e581734d6673ab0a2d9de7ccf09... if anyone’s interested. I want to release it soon. It was rather trivial, with the exception of testing if an object is an instance of Annotated – but once get_origin works with Annotated this won’t be an issue. I wanted to test mypy integration and I found an issue with aliasing I think, reported here: https://github.com/python/mypy/issues/7729 All in all the typing_extensions implementation seems to be working nicely and this PEP satisfies my needs so far. Best, Jakub
The mypy problem is just an implementation bug that should be fixed. Otherwise, I think it is fine to move towards pronouncement. If the authors agree, IIUC the next step for them is to request Steering Council for a BDFL-Delegate, and then post the current PEP text for a review by the delegate. Guido, is this right? -- Ivan On Wed, 16 Oct 2019 at 22:52, Jakub Stasiak <jakub@stasiak.at> wrote:
Let me revive the thread.
As a way to verify the design and the implementation I added Annotated-based markers to Injector (I’ve done it quickly before, now I fully tested it and did it right). https://github.com/alecthomas/injector/commit/d50e581734d6673ab0a2d9de7ccf09... if anyone’s interested. I want to release it soon.
It was rather trivial, with the exception of testing if an object is an instance of Annotated – but once get_origin works with Annotated this won’t be an issue.
I wanted to test mypy integration and I found an issue with aliasing I think, reported here: https://github.com/python/mypy/issues/7729
All in all the typing_extensions implementation seems to be working nicely and this PEP satisfies my needs so far.
Best, Jakub
Yes, this is ready to bring before the SC. On Tue, Oct 22, 2019 at 9:35 AM Ivan Levkivskyi <levkivskyi@gmail.com> wrote:
The mypy problem is just an implementation bug that should be fixed.
Otherwise, I think it is fine to move towards pronouncement. If the authors agree, IIUC the next step for them is to request Steering Council for a BDFL-Delegate, and then post the current PEP text for a review by the delegate.
Guido, is this right?
-- Ivan
On Wed, 16 Oct 2019 at 22:52, Jakub Stasiak <jakub@stasiak.at> wrote:
Let me revive the thread.
As a way to verify the design and the implementation I added Annotated-based markers to Injector (I’ve done it quickly before, now I fully tested it and did it right). https://github.com/alecthomas/injector/commit/d50e581734d6673ab0a2d9de7ccf09... if anyone’s interested. I want to release it soon.
It was rather trivial, with the exception of testing if an object is an instance of Annotated – but once get_origin works with Annotated this won’t be an issue.
I wanted to test mypy integration and I found an issue with aliasing I think, reported here: https://github.com/python/mypy/issues/7729
All in all the typing_extensions implementation seems to be working nicely and this PEP satisfies my needs so far.
Best, Jakub
-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
On 22 Oct 2019, at 19:13, Guido van Rossum <guido@python.org> wrote:
Yes, this is ready to bring before the SC.
On Tue, Oct 22, 2019 at 9:35 AM Ivan Levkivskyi <levkivskyi@gmail.com> wrote: The mypy problem is just an implementation bug that should be fixed.
Otherwise, I think it is fine to move towards pronouncement. If the authors agree, IIUC the next step for them is to request Steering Council for a BDFL-Delegate, and then post the current PEP text for a review by the delegate.
Guido, is this right?
-- Ivan
On Wed, 16 Oct 2019 at 22:52, Jakub Stasiak <jakub@stasiak.at> wrote: Let me revive the thread.
As a way to verify the design and the implementation I added Annotated-based markers to Injector (I’ve done it quickly before, now I fully tested it and did it right). https://github.com/alecthomas/injector/commit/d50e581734d6673ab0a2d9de7ccf09... if anyone’s interested. I want to release it soon.
It was rather trivial, with the exception of testing if an object is an instance of Annotated – but once get_origin works with Annotated this won’t be an issue.
I wanted to test mypy integration and I found an issue with aliasing I think, reported here: https://github.com/python/mypy/issues/7729
All in all the typing_extensions implementation seems to be working nicely and this PEP satisfies my needs so far.
Best, Jakub
-- --Guido van Rossum (python.org/~guido) Pronouns: he/him (why is my pronoun here?)
For visibility (I learned about it today by accident, maybe it’ll help someone) – this PEP has been accepted: https://github.com/python/peps/pull/1225. Congratulations! Best, Jakub
On 22 Oct 2019, at 19:13, Guido van Rossum <guido@python.org> wrote:
Yes, this is ready to bring before the SC.
On Tue, Oct 22, 2019 at 9:35 AM Ivan Levkivskyi <levkivskyi@gmail.com> wrote: The mypy problem is just an implementation bug that should be fixed.
Otherwise, I think it is fine to move towards pronouncement. If the authors agree, IIUC the next step for them is to request Steering Council for a BDFL-Delegate, and then post the current PEP text for a review by the delegate.
Guido, is this right?
-- Ivan
On Wed, 16 Oct 2019 at 22:52, Jakub Stasiak <jakub@stasiak.at> wrote: Let me revive the thread.
As a way to verify the design and the implementation I added Annotated-based markers to Injector (I’ve done it quickly before, now I fully tested it and did it right). https://github.com/alecthomas/injector/commit/d50e581734d6673ab0a2d9de7ccf09... if anyone’s interested. I want to release it soon.
It was rather trivial, with the exception of testing if an object is an instance of Annotated – but once get_origin works with Annotated this won’t be an issue.
I wanted to test mypy integration and I found an issue with aliasing I think, reported here: https://github.com/python/mypy/issues/7729
All in all the typing_extensions implementation seems to be working nicely and this PEP satisfies my needs so far.
Best, Jakub
-- --Guido van Rossum (python.org/~guido) Pronouns: he/him (why is my pronoun here?) _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/
Hey all, Since this PEP has been accepted can the typing_extensions changes be merged into CPython/typing? If there’s already effort to do that I apologize for polluting this thread – I’ve looked and I haven’t found any. If there’s not enough resources to do that I could help with this. Best regards, Jakub
IIRC I sent an e-mail to the authors privately asking to do this, but maybe they don't have time. If you would like to help, you can just coordinate with them (essentially you just need to make couple PRs to cpython and typing repos). -- Ivan On Fri, 20 Dec 2019 at 20:06, Jakub Stasiak <jakub@stasiak.at> wrote:
On 22 Oct 2019, at 19:13, Guido van Rossum <guido@python.org> wrote:
Yes, this is ready to bring before the SC.
On Tue, Oct 22, 2019 at 9:35 AM Ivan Levkivskyi <levkivskyi@gmail.com> wrote: The mypy problem is just an implementation bug that should be fixed.
Otherwise, I think it is fine to move towards pronouncement. If the authors agree, IIUC the next step for them is to request Steering Council for a BDFL-Delegate, and then post the current PEP text for a review by the delegate.
Guido, is this right?
-- Ivan
On Wed, 16 Oct 2019 at 22:52, Jakub Stasiak <jakub@stasiak.at> wrote: Let me revive the thread.
As a way to verify the design and the implementation I added Annotated-based markers to Injector (I’ve done it quickly before, now I fully tested it and did it right). https://github.com/alecthomas/injector/commit/d50e581734d6673ab0a2d9de7ccf09... if anyone’s interested. I want to release it soon.
It was rather trivial, with the exception of testing if an object is an instance of Annotated – but once get_origin works with Annotated this won’t be an issue.
I wanted to test mypy integration and I found an issue with aliasing I think, reported here: https://github.com/python/mypy/issues/7729
All in all the typing_extensions implementation seems to be working nicely and this PEP satisfies my needs so far.
Best, Jakub
-- --Guido van Rossum (python.org/~guido) Pronouns: he/him (why is my pronoun here?) _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/
Hey all,
Since this PEP has been accepted can the typing_extensions changes be merged into CPython/typing?
If there’s already effort to do that I apologize for polluting this thread – I’ve looked and I haven’t found any. If there’s not enough resources to do that I could help with this.
Best regards, Jakub
I just found this thread (which I had flagged in my inbox last month). AFAIK we still haven't heard from anyone who is interested in merging these (relatively simple) changes into the CPython master thread. Is anyone interested in volunteering? It would be a shame if the PEP were accepted but the changes weren't landed in Python 3.9! There's time until early May (when 3.9 goes into beta), but it's really better to have this in the next alpha release, so it gets some testing. PS. The release 3.9 schedule is PEP 596: https://www.python.org/dev/peps/pep-0596/ On Fri, Dec 27, 2019 at 7:58 AM Ivan Levkivskyi <levkivskyi@gmail.com> wrote:
IIRC I sent an e-mail to the authors privately asking to do this, but maybe they don't have time. If you would like to help, you can just coordinate with them (essentially you just need to make couple PRs to cpython and typing repos).
-- Ivan
On Fri, 20 Dec 2019 at 20:06, Jakub Stasiak <jakub@stasiak.at> wrote:
On 22 Oct 2019, at 19:13, Guido van Rossum <guido@python.org> wrote:
Yes, this is ready to bring before the SC.
On Tue, Oct 22, 2019 at 9:35 AM Ivan Levkivskyi <levkivskyi@gmail.com> wrote: The mypy problem is just an implementation bug that should be fixed.
Otherwise, I think it is fine to move towards pronouncement. If the authors agree, IIUC the next step for them is to request Steering Council for a BDFL-Delegate, and then post the current PEP text for a review by the delegate.
Guido, is this right?
-- Ivan
On Wed, 16 Oct 2019 at 22:52, Jakub Stasiak <jakub@stasiak.at> wrote: Let me revive the thread.
As a way to verify the design and the implementation I added Annotated-based markers to Injector (I’ve done it quickly before, now I fully tested it and did it right). https://github.com/alecthomas/injector/commit/d50e581734d6673ab0a2d9de7ccf09... if anyone’s interested. I want to release it soon.
It was rather trivial, with the exception of testing if an object is an instance of Annotated – but once get_origin works with Annotated this won’t be an issue.
I wanted to test mypy integration and I found an issue with aliasing I think, reported here: https://github.com/python/mypy/issues/7729
All in all the typing_extensions implementation seems to be working nicely and this PEP satisfies my needs so far.
Best, Jakub
-- --Guido van Rossum (python.org/~guido) Pronouns: he/him (why is my pronoun here?) _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/
Hey all,
Since this PEP has been accepted can the typing_extensions changes be merged into CPython/typing?
If there’s already effort to do that I apologize for polluting this thread – I’ve looked and I haven’t found any. If there’s not enough resources to do that I could help with this.
Best regards, Jakub
-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
On 29 Jan 2020, at 04:50, Guido van Rossum <guido@python.org> wrote:
I just found this thread (which I had flagged in my inbox last month). AFAIK we still haven't heard from anyone who is interested in merging these (relatively simple) changes into the CPython master thread. Is anyone interested in volunteering? It would be a shame if the PEP were accepted but the changes weren't landed in Python 3.9! There's time until early May (when 3.9 goes into beta), but it's really better to have this in the next alpha release, so it gets some testing.
PS. The release 3.9 schedule is PEP 596: https://www.python.org/dev/peps/pep-0596/
On Fri, Dec 27, 2019 at 7:58 AM Ivan Levkivskyi <levkivskyi@gmail.com> wrote: IIRC I sent an e-mail to the authors privately asking to do this, but maybe they don't have time. If you would like to help, you can just coordinate with them (essentially you just need to make couple PRs to cpython and typing repos).
-- Ivan
On Fri, 20 Dec 2019 at 20:06, Jakub Stasiak <jakub@stasiak.at> wrote:
On 22 Oct 2019, at 19:13, Guido van Rossum <guido@python.org> wrote:
Yes, this is ready to bring before the SC.
On Tue, Oct 22, 2019 at 9:35 AM Ivan Levkivskyi <levkivskyi@gmail.com> wrote: The mypy problem is just an implementation bug that should be fixed.
Otherwise, I think it is fine to move towards pronouncement. If the authors agree, IIUC the next step for them is to request Steering Council for a BDFL-Delegate, and then post the current PEP text for a review by the delegate.
Guido, is this right?
-- Ivan
On Wed, 16 Oct 2019 at 22:52, Jakub Stasiak <jakub@stasiak.at> wrote: Let me revive the thread.
As a way to verify the design and the implementation I added Annotated-based markers to Injector (I’ve done it quickly before, now I fully tested it and did it right). https://github.com/alecthomas/injector/commit/d50e581734d6673ab0a2d9de7ccf09... if anyone’s interested. I want to release it soon.
It was rather trivial, with the exception of testing if an object is an instance of Annotated – but once get_origin works with Annotated this won’t be an issue.
I wanted to test mypy integration and I found an issue with aliasing I think, reported here: https://github.com/python/mypy/issues/7729
All in all the typing_extensions implementation seems to be working nicely and this PEP satisfies my needs so far.
Best, Jakub
-- --Guido van Rossum (python.org/~guido) Pronouns: he/him (why is my pronoun here?) _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/
Hey all,
Since this PEP has been accepted can the typing_extensions changes be merged into CPython/typing?
If there’s already effort to do that I apologize for polluting this thread – I’ve looked and I haven’t found any. If there’s not enough resources to do that I could help with this.
Best regards, Jakub
-- --Guido van Rossum (python.org/~guido) Pronouns: he/him (why is my pronoun here?)
I agree. I asked Till and he gave me green light to merge this and I have a pull request ready for review: https://github.com/python/cpython/pull/18260 I want to emphasize one thing: since I’m importing someone else’s work I’m not sure if I did everything right – if I didn’t just let me know. Best regards, Jakub
Very nice spec, almost exactly what I was looking for for one of my experiments. There's just one thing I wanted to ask (since it's not mentioned in rejected ideas), why not "stacked" annotations? Something like name: Annotated[int][struct2.ctype('H')] is valid syntax and extra brackets would separate multiple annotations nicely. Or it could be used together with slices magic to provide some "namespacing" and potentially reduce the verbosity somewhat: name: Annotated[int][struct2:'H'] We could increase complexity even further with something like Annotated[ 'sql': 'bigint': 'Big and important int field', 'check (field < 100)', ] I checked, mixing tuples and slices is still valid syntax. No idea what mypy and other tools would think about this kind of abuse though. I'm sure there were reasons for designing it the way it's described in the spec, I was just curious whether something like above was ever considered and, if rejected, why. Annotated[::][:,:('o'):,:('o'):,:][::][""""I'm just gonna leave this here"""] Ivan.
I was just curious whether something like above was ever considered and, if rejected, why.
One can already combine multiple annotations with the current syntax Annotated[t, X, Y, Z], it is probably subjective whether this is better than Annotated[t][X][Y][Z], but I like the former one more (plus it is already implemented). -- (other) Ivan
I'm really looking forward to using this! Annotations like `ValueRange` and `MaxLen` (and `MinLen`) will be very useful indeed for tools like Hypothesis and CrossHair, allowing us to automatically infer much more precise tests for other people's code than just the type. Of course, that's only going to work if the ecosystem is reasonably consistent in how we represent numeric and size bounds, and to that end I'd like to propose that we standardise on the `slice` object. For example: ```python # numeric bounds Probability: Annotated[Real, slice(0, 1)] # all probabilities must be 0 < p < 1 Nat: Annotated[int, slice(1, None)] # natural numbers 1, 2, 3, 4, ... # collection size bounds NonEmptyList: Annotated[List[T], slice(1, None)] # self-explanatory, I hope NumpyShape: Annotated[Tuple[int, ...], slice(0, 32)] # Numpy arrays can have at most 32 dimensions ``` I would actually encourage the use of semantically meaningful aliases or wrappers (to e.g. ensure that `start is not None` for collection sizes), but using a `slice` object at runtime ensures that these common annotations are interoperable between libraries. Thoughts? If nobody objects I'm happy to write up a short PR against the docs. Cheers, Zac
Hm, using slices to indicate *real* intervals sounds odd, given the pretty strong association of slices with linear progressions of integers. Would you write slice(0, 0.5) for 0 <= p < 0.5? There's also the issue of bounds. E.g. probabilities should use the *closed* interval [0, 1], but slice() is traditionally used to mean a *half-open* interval, so slice(0, 1) would be [0, 1). Whereas you wrote 0 < p < 1 which sounds just wrong. On Tue, Mar 3, 2020 at 5:23 PM Zac Hatfield-Dodds < zac.hatfield.dodds@gmail.com> wrote:
I'm really looking forward to using this!
Annotations like `ValueRange` and `MaxLen` (and `MinLen`) will be very useful indeed for tools like Hypothesis and CrossHair, allowing us to automatically infer much more precise tests for other people's code than just the type.
Of course, that's only going to work if the ecosystem is reasonably consistent in how we represent numeric and size bounds, and to that end I'd like to propose that we standardise on the `slice` object. For example:
```python # numeric bounds Probability: Annotated[Real, slice(0, 1)] # all probabilities must be 0 < p < 1 Nat: Annotated[int, slice(1, None)] # natural numbers 1, 2, 3, 4, ...
# collection size bounds NonEmptyList: Annotated[List[T], slice(1, None)] # self-explanatory, I hope NumpyShape: Annotated[Tuple[int, ...], slice(0, 32)] # Numpy arrays can have at most 32 dimensions ```
I would actually encourage the use of semantically meaningful aliases or wrappers (to e.g. ensure that `start is not None` for collection sizes), but using a `slice` object at runtime ensures that these common annotations are interoperable between libraries.
Thoughts? If nobody objects I'm happy to write up a short PR against the docs.
Cheers, Zac _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/
-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
participants (9)
-
anishchuk.ia＠gmail.com -
Bernat Gabor -
Gregory P. Smith -
Guido van Rossum -
Ivan Levkivskyi -
Jakub Stasiak -
Till -
Vincent Siles -
Zac Hatfield-Dodds