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

assert_type: Use fully qualified types when names are ambiguous #12677

Closed
JelleZijlstra opened this issue Apr 26, 2022 · 8 comments · Fixed by #15184
Closed

assert_type: Use fully qualified types when names are ambiguous #12677

JelleZijlstra opened this issue Apr 26, 2022 · 8 comments · Fixed by #15184

Comments

@JelleZijlstra
Copy link
Member

On current master, this code:

from typing import TypeVar
import typing
import typing_extensions

U = TypeVar("U", int, typing_extensions.SupportsIndex)

def f(si: U) -> U:
    return si

def caller(si: typing.SupportsIndex):
    typing_extensions.assert_type(f(si), typing.SupportsIndex)

produces

test_cases/stdlib/itertools/mypybug.py:11: error: Expression is of type "SupportsIndex", not "SupportsIndex"

This is arguably correct, since the expression is of type typing_extensions.SupportsIndex and we wanted typing.SupportsIndex, but obviously the UX is terrible. We should output the fully qualified names.

More broadly, perhaps assert_type() should consider two protocols that define identical methods to be the same (so the assertion should pass). Curious what other people think here.

@JelleZijlstra JelleZijlstra added bug mypy got something wrong diagnostics assert-type assert_type() labels Apr 26, 2022
@jwodder
Copy link

jwodder commented Jun 1, 2022

I don't know if this is the exact same bug or not, but I just discovered that this code:

from typing_extensions import assert_type

assert_type(42, int)

fails to typecheck with mypy (both 0.960 and commit 1636a05) with the following message:

assert-type01.py:3: error: Expression is of type "int", not "int"

@JelleZijlstra
Copy link
Member Author

@jwodder wow that's unfortunate. I think it's a different problem though, could you open a new issue?

@jwodder
Copy link

jwodder commented Jun 1, 2022

@JelleZijlstra Issue created: #12923

@JukkaL
Copy link
Collaborator

JukkaL commented Apr 23, 2023

Implementation hints: to fix this, it may be sufficient to use format_type_distinctly to convert the types to strings when generating the error message.

@teresa0605
Copy link
Contributor

Hi! Is this issue still open? I would like to work on it.

@JelleZijlstra
Copy link
Member Author

Yes! Jukka's message above should provide a way to fix the issue. Feel free to ask here if you have any questions.

@teresa0605
Copy link
Contributor

from typing import TypeVar
import typing
import typing_extensions

U = TypeVar("U", int, typing_extensions.SupportsIndex)

def f(si: U) -> U:
    return si

def caller(si: typing.SupportsIndex):
    typing_extensions.assert_type(f(si), typing.SupportsIndex)

This code doesn't produce any errors in current master branch. Is this fixed already or should the behavior be outputing the fully qualified names?

@JelleZijlstra
Copy link
Member Author

JelleZijlstra commented May 2, 2023

The original repro case is a bit convoluted, not sure why I didn't do something simpler. However, consider this case:

import typing_extensions

class SupportsIndex:
    pass

def f(si: SupportsIndex):
    typing_extensions.assert_type(si, typing_extensions.SupportsIndex)

This still produces main.py:8: error: Expression is of type "SupportsIndex", not "SupportsIndex" [assert-type].

I would want it to say something like main.py:8: error: Expression is of type "my_module.SupportsIndex", not "typing_extensions.SupportsIndex" [assert-type]

hauntsaninja pushed a commit that referenced this issue May 4, 2023
Fixes #12677

When assert_type fails, when the type of value examined and the
specified type have the same name, mypy returns an error with more
descriptive and distinct names.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants