Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

gh-87390: Add tests demonstrating current type variable substitution behaviour #32341

Open
wants to merge 13 commits into
base: main
Choose a base branch
from

Conversation

Copy link
Contributor

@mrahtz mrahtz commented Apr 5, 2022

Here's a reference of what we currently do and don't allow in terms of type variable substitution in aliases. I've marked the cases that I think the current implementation is incorrect on.

Ideally I'd like to merge this as-is, even with the test cases whose expected results aren't what we think they should be - I think it'll make our job implementing the remaining fixes easier if we can just twiddle one line of an existing test case rather than having to remember to copy-paste the test case that each change fixes.

Some cases I'm unsure about are:

  • tuple[T][*tuple[int, ...]]. My understanding is that when it comes to tuple[int, ...], the current behaviour of type checkers is to "Try to find a way to make it work" - I think this should be tuple[int]?
  • class C(Generic[T1, T2]): ...; C[*tuple[int, ...], *tuple[str, ...]]. By similar reasoning, this should work - but should it be C[int, int], C[int, str], or C[str, str]?

@pradeep90 What do you think?

https://bugs.python.org/issue47006

@bedevere-bot bedevere-bot added the tests label Apr 5, 2022
Lib/test/test_typing.py Outdated Show resolved Hide resolved
@mrahtz mrahtz marked this pull request as ready for review Apr 10, 2022
Copy link
Member

@JelleZijlstra JelleZijlstra left a comment

Thanks, this is a really helpful list.

Lib/test/test_typing.py Outdated Show resolved Hide resolved
Lib/test/test_typing.py Outdated Show resolved Hide resolved
Lib/test/test_typing.py Outdated Show resolved Hide resolved
@cpython-cla-bot
Copy link

@cpython-cla-bot cpython-cla-bot bot commented Apr 11, 2022

All commit authors signed the Contributor License Agreement.
CLA signed

@mrahtz mrahtz changed the title bpo-47006: Add tests demonstrating current type variable substitution behaviour gh-87390: Add tests demonstrating current type variable substitution behaviour Apr 11, 2022
@mrahtz
Copy link
Contributor Author

@mrahtz mrahtz commented Apr 11, 2022

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 TypeError, because it looks like we're passing only a single argument *tuple[int, str] to an alias that expects two arguments.

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 *tuple[int, str] actually counts for, but that seems like it could get messy.

@mrahtz
Copy link
Contributor Author

@mrahtz mrahtz commented Apr 15, 2022

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 *tuple[int, str]. I've added another test case for this scenario.

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'd rather leave this as is. If we simplify it, we make it impossible for runtime introspection to even tell the difference.

I do agree that for the particular case of *tuple[int, ...] we should leave it unsimplified. I think the only alias involving *tuple[int, ...] that should be valid at runtime for now is generic[*Ts][*tuple[int, ...]].

I'll update the tests accordingly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants