Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Should we remove sametypes.py? #7924

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.

Sign up for GitHub

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

Jump to bottom
Closed
ilevkivskyi opened this issue Nov 11, 2019 · 4 comments · Fixed by #13311
Closed

Should we remove sametypes.py? #7924

ilevkivskyi opened this issue Nov 11, 2019 · 4 comments · Fixed by #13311
Labels
needs discussion priority-1-normal refactoring Changing mypy's internals topic-developer Issues relevant to mypy developers

Comments

@ilevkivskyi
Copy link
Member

There are two ways we can compare types for being the same:

  • Semantic identity, this is what is done by is_equivalent() that just checks A <: B and B <: A. This affects semantics of types in the user code being checked.
  • Representation identity, this is what is currently done by Type.__eq__() and Type.__hash__(). This affects internal bookkeeping, caching, etc.

Currently, is_same_types() stays somewhere in the middle, it doesn't take into account some subtype relationships (including protocols and recursive type aliases), but it also "takes into account" make_simplified_union().

I could see how this can be a minor performance optimization for equivalence with respect to proper subtyping, but IMO this kind of middle ground position increases chance for confusion and bugs. I would propose to remove it and instead use == and is_equivalent().
@msullivan
Copy link
Collaborator

To be honest it's never been totally clear to me what it was for.

@JukkaL
Copy link
Collaborator

JukkaL commented Nov 12, 2019

It would be great if we can merge == and is_same_type(). I'm not sure how feasible this is, however. This needs to be done carefully, since == and is_same_type() currently behave differently. For example, an UnboundType instance is considered the "same" as any other type, and a single-item union is the same as the item type.

is_equivalent is a different beast since it treats Any as special.

Here are my proposed next steps if somebody wants to take this:

  1. Review how the two operations behave for every type combination. Update the semantics to be equivalent when deviations are found. This could a series of PRs if there are several needed changes, since the changes can cause subtle backward compatibility issues.
  2. Once the two operations behave the same, delete one of them.

@ilevkivskyi
Copy link
Member Author

For example, an UnboundType instance is considered the "same" as any other type, and a single-item union is the same as the item type.

I think we should use is_equivalent() for cases where this is needed, potentially with proper_subtype=True.

is_equivalent is a different beast since it treats Any as special.

Again, there just should be an proper_type flag to this function. Probably as a result of fixing #3297 as you proposed in #3297 (comment) by adding a flag to the visitor instead of having two visitors.

Here are my proposed next steps if somebody wants to take this:

I have a slightly different plan like gradually removing is_same_types() in favour of either == or is_equivalent(). Also we can keep is_proper_subtype() as a shortcut for is_subtype(proper_subtype=True) and potentially is_same_types() as a shortcut for is_equivalent(proper_subtype=True).

@JukkaL
Copy link
Collaborator

JukkaL commented Nov 12, 2019

I think we should use is_equivalent() for cases where this is needed, potentially with proper_subtype=True.

I still think that is_equivalent and is_same_type (or whatever it will be replaced with) should be kept as separate operations. I'd like to avoid adding additional boolean flags that change the semantics of operations significantly, unless perhaps the alternative is messy to implement, which doesn't seem to be the case here.

However, adding a new function that replacesis_same_type and that does a two-way proper subtype check sounds like a good idea to try out. (I'm only opposed to adding the functionality to is_equivalent.)

Also, the names of various type functions are kind of confusing, but that'a a separate issue.

@97littleleaf11 97littleleaf11 mentioned this issue Feb 18, 2022
Merged
1 task
@AlexWaygood AlexWaygood added the topic-developer Issues relevant to mypy developers label Apr 8, 2022
@ilevkivskyi ilevkivskyi mentioned this issue Aug 2, 2022
Merged
ilevkivskyi added a commit that referenced this issue Aug 4, 2022
@ilevkivskyi
Delete sametypes.py (#13311)
7251ef8 
Fixes #7924

So this is not 100% refactor, I make several semantic changes. As discussed in the issue, current implementation is not very principled, so I replace old complex logic with two options:
* New `is_same_types()` is now located in `subtypes.py` and is doing two-way proper subtyping check.
* Type equality with `==` can be used when we are checking for representation equality (used rarely, mostly for internal things)

Btw this uncovered two actual bugs, one of which I fix here (two-line change), and leave a TODO for the second.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
needs discussion priority-1-normal refactoring Changing mypy's internals topic-developer Issues relevant to mypy developers
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Delete sametypes.py ilevkivskyi/mypy
4 participants
@msullivan @JukkaL @ilevkivskyi @AlexWaygood