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

mypy is unhappy with repeated use of _ as a throw-away variable #1332

Closed
ddfisher opened this issue Apr 5, 2016 · 10 comments
Closed

mypy is unhappy with repeated use of _ as a throw-away variable #1332

ddfisher opened this issue Apr 5, 2016 · 10 comments

Comments

@ddfisher
Copy link
Collaborator

ddfisher commented Apr 5, 2016

_ is commonly used as a throw-away variable in list unpacking, but this will make mypy unhappy if two lists with different types are unpacked in the same function. For example

x, _ = ["foo", "bar"]
n, _ = [1, 2]

results in:

test.py:2: error: Incompatible types in assignment (expression has type "int", variable has type "str")

To support this pattern, we may want to consider special-casing _ and not generating this sort of type error if the variable is never read.

@gvanrossum
Copy link
Member

A complication is that _ is also commonly used as an alias for gettext. When we see an import like from ... import gettext as _ we should not special-case it (and probably complain extra loudly if _ is redefined locally).

@JukkaL
Copy link
Collaborator

JukkaL commented Apr 5, 2016

In the gettext use case _ it will be accessed within the module. As @ddfisher suggested, perhaps we should only special case _ if it's never read.

@JukkaL JukkaL added the feature label Apr 7, 2016
@gvanrossum gvanrossum added this to the 0.4.0 milestone Apr 7, 2016
@dmoisset
Copy link
Contributor

dmoisset commented Jun 9, 2016

In my opinion, any variable (no matter its name) which is used only write only can be safely typed to Any (or to object), given that this can never be an unsafe operation, so it's sound and cover this pattern well (and some alternative things like using __ as placeholder)

@JukkaL
Copy link
Collaborator

JukkaL commented Jun 9, 2016

At module and class top levels we can't determine whether a variable will be read outside the module/class, so at least here a naming convention helps.

@dmoisset
Copy link
Contributor

dmoisset commented Jun 9, 2016

Yes, my comment was made thinking about locals

@dmoisset
Copy link
Contributor

A note that may help clean up the issue tracker: this seems to be the same issue as #465 and #1649, they can probably be unified

@ddfisher
Copy link
Collaborator Author

Instead of special casing write-only variables to have the Any type, we could also just be willing to infer Union types for things. E.g.:

_ = 1
_ = "foo"
# _ now has type Union[int, str]

Come to think of it, this would likely also solve the "variable must only have a single type" problem (provided that is something we want to solve) because of the way we already understand assignments to Union types.

@gvanrossum
Copy link
Member

gvanrossum commented Jun 10, 2016 via email

@ddfisher
Copy link
Collaborator Author

Not necessarily! We add more specific types to the binder on assignment, so e.g.:

from typing import Union

x = 0  # type: Union[str, int]
x = "foo"
reveal_type(x)  # Revealed type is 'builtins.str'
x = 0
reveal_type(x)  # Revealed type is 'builtins.int'

@JukkaL
Copy link
Collaborator

JukkaL commented Mar 3, 2017

Closing this as a duplicate of #465.

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

No branches or pull requests

4 participants