GeezerVisonThe World Wide Web, restored to 800 pixels of glory. | |||||||||||||||||
| Home|About|Gaming cabinet|Archives|How it works|Starter sites | |||||||||||||||||
GeezerVison is showing github.com — gh-87390: Add tests demonstrating current type variable substitution behaviour by mrahtz · Pull Request #32341 · python/cpython Conversation
|
|
Re @JelleZijlstra's suggestion (if I understood right?) to leave unpacked tuples unsimplified across the board: I just realised this means we might have to ease up on checks for the right number of arguments across the board. For example: tuple[T1, T2][*tuple[int, str]] This should be valid, but I think at the moment it would trigger a I guess easing up on type argument number checks should be fine though? The alternative would be to have some fancy logic that tries to detect how many type arguments something like |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
Actually, having thought about it more over the past few days, I don't think leaving unpacked tuples unsimplified in all case will work. For example, if we did: Alias = tuple[T1, bool, T2] Alias[*tuple[int, str]] # Should be tuple[int, bool, str] There's no way we could properly evaluate the result of that unless we did unpack Having said that, Jelle, I'm still bearing in mind your comment: 'generic[T]', '[*tuple_type[int, ...]]', 'generic[*tuple_type[int, ...]]' # Should be generic[int]?
I do agree that for the particular case of I'll update the tests accordingly. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
(Damn, GitHub doesn't make it obvious at all whether you've submitted a review or not. I thought I'd submitted this days ago.)
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
| ('tuple[T, *Ts]', '[int, str, bool]', 'TypeError'), # Should be tuple[int, str, bool] | ||
| ('Tuple[T, *Ts]', '[int, str, bool]', 'Tuple[int, str, bool]'), | ||
|
|
||
| ('C[T, *Ts]', '[*tuple_type[int, ...]]', 'C[*tuple_type[int, ...]]'), # Should be C[int, *tuple_type[int, ...]] |
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
For what it's worth, there won't be an observable difference from the type checking point of view. For example, if someone tries to pass in this instantiated alias C[*tuple[int, ...]] to a function that expects C[A, *Rs], they will still get A=int, Rs=tuple[int, ...].
So, we have some freedom in what to do here. If getting C[int, *tuple[int, ...]] is hard, it might be ok to keep C[*tuple[int, ...]]
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
I think this is a case I updated since your review. The vibe I'm getting from @JelleZijlstra is that the kind of logic complexity he'd be happy with (correct me if I'm wrong, @JelleZijlstra) wouldn't be up to dealing with C[T, *Ts][*tuple[int, ...]] - either figuring out the 'right' answer of C[int, *tuple[int, ...]], or accepting it as valid and giving the mostly-right answer of C[*tuple[int, ...]].
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
In fact, according to the updated tentative spec at #91162, we'd disallow this altogether - we wouldn't allow any cases where *tuple[int, ...] has to be split among multiple things.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
|
I came across a case in the typing-extensions tests that is not covered here yet: from typing import * Ts = TypeVarTuple('Ts') T1 = TypeVar('T') T2 = TypeVar('T') class C(Generic[T1, T2, Unpack[Ts]]): pass with self.assertRaises(TypeError): C[int] typing.py currently accepts this without errors. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
- Defer to the PEP 646 implementation in typing.py on 3.11 - Adjust some tests accordingly. Noted a bug in python/cpython#32341 (comment) - typing._type_check() is more lenient in 3.11 and no longer rejects ints - The representation of the empty tuple type changed Tests pass for me on a 3.11 build from today now.
For the time being, this intentional - we decided not to check arity at runtime for variadics (https://github.com/python/cpython/blob/main/Lib/typing.py#L1331). |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
- Defer to the PEP 646 implementation in typing.py on 3.11 - Adjust some tests accordingly. Noted a bug in python/cpython#32341 (comment) - typing._type_check() is more lenient in 3.11 and no longer rejects ints - The representation of the empty tuple type changed Tests pass for me on a 3.11 build from today now.
…id arguments for a *Ts
…o* now get a TypeError
|
Going to merge this now so we have the test framework. We'll likely adjust some of the cases though. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
- Defer to the PEP 646 implementation in typing.py on 3.11 - Adjust some tests accordingly. Noted a bug in python/cpython#32341 (comment) - typing._type_check() is more lenient in 3.11 and no longer rejects ints - The representation of the empty tuple type changed Tests pass for me on a 3.11 build from today now.
- Defer to the PEP 646 implementation in typing.py on 3.11 - Adjust some tests accordingly. Noted a bug in python/cpython#32341 (comment) - typing._type_check() is more lenient in 3.11 and no longer rejects ints - The representation of the empty tuple type changed Tests pass for me on a 3.11 build from today now.
- Defer to the PEP 646 implementation in typing.py on 3.11 - Adjust some tests accordingly. Noted a bug in python/cpython#32341 (comment) - typing._type_check() is more lenient in 3.11 and no longer rejects ints - The representation of the empty tuple type changed Tests pass for me on a 3.11 build from today now.
There was an error while loading. Please reload this page.
Successfully merging this pull request may close these issues.
There was an error while loading. Please reload this page.