GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • Sign in
  • ActionsCI/CD and automation
  • CodespacesCloud development environments
  • All Features
  • Documentation
  • Training
  • Certifications
  • Build with Copilot
  • Customize Copilot
  • Integrations
  • Trending repos
  • GitHub Sponsors
  • Developer articles
  • Enterprises

This view

  • Original page
  • New address

GeezerVison is showing github.com — gh-87390: Add tests demonstrating current type variable substitution behaviour by mrahtz · Pull Request #32341 · python/cpython

Conversation

@mrahtz

@mrahtz mrahtz commented Apr 5, 2022 •
edited
Loading

Uh oh!

There was an error while loading. Please reload this page.

Copy link
Copy Markdown
Contributor

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

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

All reactions
@mrahtz
Add integration tests for type variable substitution
f508d12
@bedevere-bot bedevere-bot added the awaiting review label Apr 5, 2022
@the-knights-who-say-ni the-knights-who-say-ni added the CLA signed label Apr 5, 2022
@bedevere-bot bedevere-bot added the tests Tests in the Lib/test dir label Apr 5, 2022
gvanrossum
gvanrossum reviewed Apr 6, 2022
View reviewed changes
Comment thread Lib/test/test_typing.py Resolved

Uh oh!

There was an error while loading. Please reload this page.

mrahtz added 6 commits April 8, 2022 21:56
@mrahtz
Add tests for list, dict and tuple
ea104b9
@mrahtz
Add tests for Tuple
526d9e8
@mrahtz
Revert "Add tests for Tuple"
0f022db
This reverts commit 526d9e8.
@mrahtz
Make it easier to tests all tuple, list and dict types
cc7bf8c
@mrahtz
TypeVarSubstitutionTests -> GenericAliasSubstitutionTests
458b5dd
@mrahtz
Remove question marks from cases I'm actually pretty sure about
0c8ba38
@mrahtz
mrahtz marked this pull request as ready for review April 10, 2022 09:40
@mrahtz
mrahtz requested review from Fidget-Spinner and JelleZijlstra as code owners April 10, 2022 09:40
JelleZijlstra
JelleZijlstra reviewed Apr 11, 2022
View reviewed changes

@JelleZijlstra JelleZijlstra left a comment

Copy link
Copy Markdown
Member

There was a problem hiding this comment.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, this is a really helpful list.

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

All reactions
Comment thread Lib/test/test_typing.py Resolved

Uh oh!

There was an error while loading. Please reload this page.

Comment thread Lib/test/test_typing.py Resolved

Uh oh!

There was an error while loading. Please reload this page.

Comment thread Lib/test/test_typing.py Resolved

Uh oh!

There was an error while loading. Please reload this page.

@mrahtz
Note that list[] should only take one argument
db24e70
@ghost

ghost commented Apr 11, 2022 •
edited by ghost
Loading

Uh oh!

There was an error while loading. Please reload this page.

Copy link
Copy Markdown

All commit authors signed the Contributor License Agreement.
CLA signed

All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

mrahtz added 2 commits April 11, 2022 19:23
@mrahtz
Leave unpacked tuples unsimplified
15a4809
@mrahtz
Add generic[*Ts][*tuple[*Ts]]
0d7d2eb
@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

mrahtz commented Apr 11, 2022

Copy link
Copy Markdown
Contributor Author

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.

All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

@mrahtz
Update comments based on decision to leave unpacked tuples unsimplified
ab01c8a
@JelleZijlstra JelleZijlstra mentioned this pull request Apr 11, 2022
PEP 646: Decide on substitution behavior #91162
Closed
@AlexWaygood AlexWaygood added the topic-typing label Apr 13, 2022
@mrahtz
Add tests for generic[T1, bool, T2][*tuple[int, str]]
c4fe922
@mrahtz

mrahtz commented Apr 15, 2022

Copy link
Copy Markdown
Contributor Author

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.

All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

@mrahtz
Update comments based on decision to unpack *some* tuples
d55b8fb
pradeep90
pradeep90 approved these changes Apr 15, 2022
View reviewed changes

@pradeep90 pradeep90 left a comment •
edited
Loading

Uh oh!

There was an error while loading. Please reload this page.

Copy link
Copy Markdown
Contributor

There was a problem hiding this comment.

Choose a reason for 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.

Uh oh!

There was an error while loading. Please reload this page.

mrahtz reacted with laugh emoji
All reactions
  • 😄 1 reaction
Comment thread Lib/test/test_typing.py Resolved

Uh oh!

There was an error while loading. Please reload this page.

Comment thread Lib/test/test_typing.py Resolved

Uh oh!

There was an error while loading. Please reload this page.

Comment thread Lib/test/test_typing.py Resolved

Uh oh!

There was an error while loading. Please reload this page.

Comment thread Lib/test/test_typing.py Resolved

Uh oh!

There was an error while loading. Please reload this page.

Comment thread Lib/test/test_typing.py Resolved

Uh oh!

There was an error while loading. Please reload this page.

Comment thread Lib/test/test_typing.py Resolved

Uh oh!

There was an error while loading. Please reload this page.

Comment thread Lib/test/test_typing.py Outdated
('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, ...]]

@pradeep90 pradeep90 Apr 12, 2022

Copy link
Copy Markdown
Contributor

There was a problem hiding this comment.

Choose a reason for 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.

Uh oh!

There was an error while loading. Please reload this page.

All reactions

@mrahtz mrahtz Apr 16, 2022 •
edited
Loading

Uh oh!

There was an error while loading. Please reload this page.

Copy link
Copy Markdown
Contributor Author

There was a problem hiding this comment.

Choose a reason for 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.

Uh oh!

There was an error while loading. Please reload this page.

All reactions

@mrahtz mrahtz Apr 16, 2022

Copy link
Copy Markdown
Contributor Author

There was a problem hiding this comment.

Choose a reason for 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.

Uh oh!

There was an error while loading. Please reload this page.

All reactions
Comment thread Lib/test/test_typing.py Resolved

Uh oh!

There was an error while loading. Please reload this page.

@bedevere-bot bedevere-bot added awaiting core review and removed awaiting review labels Apr 15, 2022
pradeep90
pradeep90 reviewed Apr 15, 2022
View reviewed changes
Comment thread Lib/test/test_typing.py Resolved

Uh oh!

There was an error while loading. Please reload this page.

@JelleZijlstra

JelleZijlstra commented Apr 15, 2022

Copy link
Copy Markdown
Member

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.

All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

JelleZijlstra added a commit to JelleZijlstra/typing that referenced this pull request Apr 15, 2022
@JelleZijlstra
Fix tests on Python 3.11
4bea386
- 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.
@JelleZijlstra JelleZijlstra mentioned this pull request Apr 15, 2022
Fix tests on Python 3.11 python/typing#1139
Merged
mrahtz added 4 commits April 16, 2022 17:45
@mrahtz
Note that generic[*tuple[()]] should raise TypeError
e858fc6
@mrahtz
Note that C[T, *tuple[int, ...]][int] raises TypeError only because C…
3bc7d26
… is non-variadic
@mrahtz
State that multiple unpackings should be allowed where possible
c980e4f
@mrahtz
Add test for generic[T1, *tuple[int, ...], T2][str, bool, float]
95b7210
@mrahtz

mrahtz commented Apr 16, 2022

Copy link
Copy Markdown
Contributor Author

[@JelleZijlstra]

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.

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).

JelleZijlstra reacted with thumbs up emoji
All reactions
  • 👍 1 reaction

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

@mrahtz
Update comments according to revised tentative spec at python#91162
96394b1
JelleZijlstra added a commit to python/typing that referenced this pull request Apr 16, 2022
@JelleZijlstra
Fix tests on Python 3.11 (#1139)
783c8ca
- 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.
mrahtz added 6 commits April 18, 2022 08:14
@mrahtz
Update expected comments to account for unpacked types only being val…
ed9a557
…id arguments for a *Ts
@mrahtz
Merge branch 'main' into subst-tests
faa9fc3
@mrahtz
Update to reflect results after merging latest main
9947fc0
@mrahtz
Update ALL tests to reflect results after merging latest main
12496fc
@mrahtz
Remove comments saying we should get a TypeError in cases where we *d…
db9af53
…o* now get a TypeError
@mrahtz
Update comments on expected results based on latest tentative spec at p…
c5b5a63
…ython#91162
@JelleZijlstra JelleZijlstra added the skip news label Apr 29, 2022
@JelleZijlstra JelleZijlstra self-assigned this Apr 29, 2022
@JelleZijlstra

JelleZijlstra commented Apr 29, 2022

Copy link
Copy Markdown
Member

Going to merge this now so we have the test framework. We'll likely adjust some of the cases though.

All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

@JelleZijlstra
JelleZijlstra merged commit f665616 into python:main Apr 29, 2022
@bedevere-bot bedevere-bot removed the awaiting core review label Apr 29, 2022
@mrahtz
mrahtz deleted the subst-tests branch April 29, 2022 20:15
@mrahtz mrahtz mentioned this pull request May 7, 2022
gh-91162: Fix substitution of unpacked tuples in generic aliases #92335
Merged
JelleZijlstra added a commit to python/typing_extensions that referenced this pull request May 19, 2022
@JelleZijlstra
Fix tests on Python 3.11 (#1139)
67b187e
- 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.
JelleZijlstra added a commit to python/typing_extensions that referenced this pull request May 19, 2022
@JelleZijlstra
Fix tests on Python 3.11 (#1139)
58f7043
- 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.
JelleZijlstra added a commit to python/typing_extensions that referenced this pull request May 19, 2022
@JelleZijlstra
Fix tests on Python 3.11 (#1139)
48a5fe0
- 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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@JelleZijlstra JelleZijlstra JelleZijlstra left review comments
@gvanrossum gvanrossum gvanrossum left review comments
@Fidget-Spinner Fidget-Spinner Awaiting requested review from Fidget-Spinner
+1 more reviewer
@pradeep90 pradeep90 pradeep90 approved these changes
Reviewers whose approvals may not affect merge requirements

Uh oh!

There was an error while loading. Please reload this page.

Assignees

@JelleZijlstra JelleZijlstra

Labels

skip news tests Tests in the Lib/test dir topic-typing

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

Uh oh!

There was an error while loading. Please reload this page.

7 participants

@mrahtz @JelleZijlstra @pradeep90 @gvanrossum @the-knights-who-say-ni @bedevere-bot @AlexWaygood
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
You are visitor 01402503 — GeezerVison does not store the pages you look up.
Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.