Message415752
> Alias = C[T, *Ts]
> Alias2 = Alias[*tuple[int, ...]]
> # Alias2 should be C[int, *tuple[int, ...]]
tuple[int, ...] includes also an empty tuple, and in this case there is no value for T.
> Oh, also interesting - I didn't know about this one either. Could you give an example?
If __origin__, __parameters__, __args__ are a mess, it will definitely break a code which use them.
> We actually deliberately chose not to unpack concrete tuple types - see the description of https://github.com/python/cpython/pull/30398, under the heading 'Starred tuple types'. (If you see another way around it, though, let me know.)
You assumed that *tuple[str, bool] in def foo(*args: *tuple[str, bool]) should give foo.__annotations__['args'] = tuple[str, bool], but it should rather give (str, bool). No confusion with tuple[str, bool].
And one of PEP 646 options is to implement star-syntax only in subscription, not in var-parameter type annotations.
> I'm also not sure about this one; disallowing unpacked TypeVarTuples in argument lists to generic aliases completely (if I've understood right?)
No, it will only be disallowed in substitution of a VarType. Tuple[T][*Ts] -- error. Tuple[*Ts][*Ts2] -- ok.
I propose to implement simple and strict rules, and later add support of new cases where it makes sense. |
|
Date |
User |
Action |
Args |
2022-03-22 08:49:01 | serhiy.storchaka | set | recipients:
+ serhiy.storchaka, gvanrossum, JelleZijlstra, kj, matthew.rahtz, mrahtz, AlexWaygood |
2022-03-22 08:49:01 | serhiy.storchaka | set | messageid: <1647938941.56.0.667038828617.issue47006@roundup.psfhosted.org> |
2022-03-22 08:49:01 | serhiy.storchaka | link | issue47006 messages |
2022-03-22 08:49:01 | serhiy.storchaka | create | |
|