Matthew Rahtz added the comment:
Ok, https://github.com/python/cpython/pull/32341/files is a reference of how
the current implementation behaves. Fwiw, it *is* mostly correct - with a few
minor tweaks it might be alright for at least the 3.11 release.
In particular, instead of dealing
Change by Matthew Rahtz :
--
keywords: +patch
pull_requests: +30396
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/32341
___
Python tracker
<https://bugs.python.org/issu
Matthew Rahtz added the comment:
[Guido]
> 1. Some edge case seems to be that if *tuple[...] is involved on either side
> we will never simplify.
Alright, let me think this through with some examples to get my head round it.
It would prohibit the following difficult case:
class C(G
Matthew Rahtz added the comment:
Apologies for the slow reply - coming back to this now that the docs and
pickling issues are mostly sorted.
[Serhiy]
> > Alias = C[T, *Ts]
> > Alias2 = Alias[*tuple[int, ...]]
> > # Alias2 should be C[int, *tuple[int, ...]]
>
> tuple
Matthew Rahtz added the comment:
> 1. Finish writing docs
Done once https://github.com/python/cpython/pull/32103 is merged.
> 2. Implement support for pickling of unpacked native tuples
Done once https://github.com/python/cpython/pull/32159 is merged.
4. Resolve the issue of
Change by Matthew Rahtz :
--
pull_requests: +30237
pull_request: https://github.com/python/cpython/pull/32159
___
Python tracker
<https://bugs.python.org/issue43
Matthew Rahtz added the comment:
Since things are piling up, here's a quick record of what I think the remaining
tasks are: (in approximate order of priority)
1. Finish writing docs (is updating library/typing.html sufficient?
https://github.com/python/cpython/pull/32103)
2. Implement
Change by Matthew Rahtz :
--
pull_requests: +30197
pull_request: https://github.com/python/cpython/pull/32119
___
Python tracker
<https://bugs.python.org/issue43
Change by Matthew Rahtz :
--
keywords: +patch
pull_requests: +30183
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/32103
___
Python tracker
<https://bugs.python.org/issu
Matthew Rahtz added the comment:
Ooh, thanks for the reminder! I'll start drafting this now.
--
nosy: +matthew.rahtz
___
Python tracker
<https://bugs.python.org/issue47
Matthew Rahtz added the comment:
P.s. To be clear, (I think?) these are all substitutions that are computable.
We *could* implement the logic to make all these evaluate correctly if we
wanted to. It's just a matter of how much complexity we want to allow in
typing.py (or in the runtime
Matthew Rahtz added the comment:
[Guido]
> What would be an example of a substitution that's too complex to do?
We also need to remember the dreaded arbitrary-length tuple. For example, I
think it should be the case that:
```python
T = TypeVar('T')
Ts = TypeVarTuple('Ts')
class C(Gene
Matthew Rahtz added the comment:
(Having said that, to be clear: my preferred solution currently would still be
the solution where we just return a new GenericAlias for anything involving a
TypeVarTuple. The crux is what Serhiy is happy
Matthew Rahtz added the comment:
Thanks for starting this, Jelle - I was a bit unsure about how to proceed here.
Given that https://github.com/python/cpython/pull/31800 is already merged, I'd
also propose something halfway between the two extremes: return a sensible
substitution when
Change by Matthew Rahtz :
--
pull_requests: +29945
pull_request: https://github.com/python/cpython/pull/31846
___
Python tracker
<https://bugs.python.org/issue43
Change by Matthew Rahtz :
--
pull_requests: +29944
pull_request: https://github.com/python/cpython/pull/31845
___
Python tracker
<https://bugs.python.org/issue43
Change by Matthew Rahtz :
--
pull_requests: +29943
pull_request: https://github.com/python/cpython/pull/31844
___
Python tracker
<https://bugs.python.org/issue43
Change by Matthew Rahtz :
--
pull_requests: +29905
pull_request: https://github.com/python/cpython/pull/31804
___
Python tracker
<https://bugs.python.org/issue43
New submission from Matthew Rahtz :
There's currently not much documentation in `typing.py` for `_GenericAlias`.
Some fairly weird things go on in there, so it would be great to have more info
in the class about what's going on and why various edge cases are necessary.
--
components
Change by Matthew Rahtz :
--
pull_requests: +29202
pull_request: https://github.com/python/cpython/pull/31021
___
Python tracker
<https://bugs.python.org/issue43
Change by Matthew Rahtz :
--
pull_requests: +29200
pull_request: https://github.com/python/cpython/pull/31019
___
Python tracker
<https://bugs.python.org/issue43
Change by Matthew Rahtz :
--
pull_requests: +29199
pull_request: https://github.com/python/cpython/pull/31018
___
Python tracker
<https://bugs.python.org/issue43
Change by Matthew Rahtz :
--
pull_requests: +28607
pull_request: https://github.com/python/cpython/pull/30398
___
Python tracker
<https://bugs.python.org/issue43
Change by Matthew Rahtz :
--
components: +Parser, Tests
nosy: +lys.nikolaou, pablogsal
title: Add support for PEP 646 (Variadic Generics) to typing.py -> Add support
for PEP 646
versions: +Python 3.11 -Python 3.10
___
Python tracker
<
Change by Matthew Rahtz :
--
keywords: +patch
nosy: +matthew.rahtz
nosy_count: 1.0 -> 2.0
pull_requests: +23313
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/24527
___
Python tracker
<https://bugs.p
Change by Matthew Rahtz :
--
components: Library (Lib)
nosy: mrahtz
priority: normal
severity: normal
status: open
title: Add support for PEP 646 (Variadic Generics) to typing.py
versions: Python 3.10
___
Python tracker
<https://bugs.python.
26 matches
Mail list logo
