René's URL Explorer Experiment

Title: bpo-43224: Draft implementation of PEP 646 by mrahtz · Pull Request #30398 · python/cpython · GitHub

Open Graph Title: bpo-43224: Draft implementation of PEP 646 by mrahtz · Pull Request #30398 · python/cpython

X Title: bpo-43224: Draft implementation of PEP 646 by mrahtz · Pull Request #30398 · python/cpython

Description: PEP 646 (Variadic Generics) hasn't yet been completely approved by the steering council, but here's a draft of its implementation so we can get started on code review. Update 2021-01-19: the SC has approved the PEP, so full steam ahead! TODO: Finish addressing @pradeep90's comments from the previous PR, #24527 Add tests for typing.get_args and typing.get_origin (rather than just checking __args__ etc) A couple of notes below. @pradeep90 @gvanrossum @Fidget-Spinner Starred tuple types I realised there's a tricky issue with starred tuple types. If we have e.g. tuple[int, *tuple[str, bool]], the obvious thing to do would be to unpack the inner tuple at runtime, resulting in tuple[int, str, bool]. This would imply that iter(tuple[str, bool]) creates an iterator returning str then bool. But this would cause problems when using starred tuple types as the type of *args, e.g. def foo(*args: *tuple[str, bool]): The type of foo.__annotations__['args'] should definitely not be tuple[str, bool]. That would instead imply def foo(*args: tuple[str, bool]) The current PEP draft states that when a starred object is used as the annotation of *args, its iterator should return only a single value. (Or at least, this is the behaviour specified for *args: *Ts; @pradeep90, I've just realised, should we update that section of the PEP to make it explicit that that starred tuples can be also used for *args?) I think the simplest solution to both of these problems is to not unpack tuple types as runtime, having *tuple[stuff] instead creating an iterator that returns only a single item, an instance of a new 'starred tuple'. (Note that such a type does have to exist anyway, in order to represent e.g. *tuple[int, ...].) For the native tuple type, I've tentatively implemented this by adding a new starred flag to gaobject in genericaliasobject.c rather than creating a whole new type. This makes implementation easier, but maybe it's suboptimal considering that gaobject is used for lots of things other than tuple - feedback appreciated. For typing.Tuple, I've implemented a new class in typing.py called StarredTuple, which should behave in the same way. (This does mean that *tuple[int] != *Tuple[int], but given that tuple[int] != Tuple[int], this seems fine.) Implementation of *tuple I'm pretty uncertain about my implementation in genericaliasobject.c. In particular: I don't know what I'm doing with garbage collection; scrutiny on whether I'm doing it right appreciated. I wonder whether there's a way to make it simpler. In typing.py, the implementation is as simple as def __iter__(self): yield StarredTuple(self). Is there a way to do something similar in ga_iter, without the need to also implement ga_iternext? https://bugs.python.org/issue43224

Open Graph Description: PEP 646 (Variadic Generics) hasn't yet been completely approved by the steering council, but here's a draft of its implementation so we can get started on code review. Update 2021-01-19: th...

X Description: PEP 646 (Variadic Generics) hasn't yet been completely approved by the steering council, but here's a draft of its implementation so we can get started on code review. Update 2021-0...

Opengraph URL: https://github.com/python/cpython/pull/30398

X: @github

direct link

Domain: github.com

Links:

Viewport: width=device-width