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

Removing ambiguity from the creation of a simple type alias #5779

Closed
JukkaL opened this issue Oct 12, 2018 · 5 comments
Closed

Removing ambiguity from the creation of a simple type alias #5779

JukkaL opened this issue Oct 12, 2018 · 5 comments

Comments

@JukkaL
Copy link
Collaborator

JukkaL commented Oct 12, 2018

Currently assignments like these are somewhat ambiguous -- they can define a variable that refers to a type object or a type alias:

X = str

Currently the assignment creates a variable in function scope and a type alias elsewhere. This is pretty confusing -- see #5769 for an example.

There are a few things that could help:

  1. Introduce a new type alias constructor, such as X = TypeAlias(str) that forces the creation of a type alias. If we report an invalid type due to a misinterpreted type alias, we can perhaps suggest using TypeAlias(...).
  2. Always create a type alias, even in functions. If this seems to cause a false positive, maybe we can generate an error about how to work around this by using a Type[foo] variable annotation.

This is only a problem with simple type aliases. Aliases like X = List[int] are always treated as type aliases.

@ilevkivskyi Thoughts about this?

@ilevkivskyi
Copy link
Member

There is already mypy_extensions.FlexibleAlias, that can be extended to support all use cases where implicit rules don't work:

  • Force creation of a type alias: Name = FlexibleAlias[str] (not supported yet)
  • Force a given number of type variables for a type alias: Dummy = FlexibleAlias[T, S, str] (currently only supports single type variable IIRC)
  • Allow alias targets that are normally prohibited Idem = FlexibleAlias[T, T] (already supported and used for mypyc)

I however don't want to rename it to just TypeAlias, because people will often use it although it is not necessary in 99.9% of cases.

Also in my experience, the situations where people actually need an alias X = str (and not X = NewType('X', str)) are very rare, so I would avoid making this the default, since this indeed causes loads of false positives.

@sinancepel
Copy link
Contributor

I wanted to chime in here from the perspective of string annotations - right now, it's hard for readers as well as type checkers to detect that Alias is a type in the below example:

if typing.TYPE_CHECKING:
  from circular_dependency import Annotation
# some code here
Alias = "Annotation"

Because of this, we have to over-approximate the set of possible type aliases in Pyre to include every assignment to a string that matches a known type. I think there's value in supporting some sort of explicit type alias syntax, this problem doesn't seem mypy-specific :)

@ilevkivskyi
Copy link
Member

For the string problem there are two solutions/workarounds:

  • A hacky one Alias = Union['Annotation']
  • A verbose one if TYPE_CHECKING: Alias = Annotation, then use 'Alias'

TBH I have never had this problem before, but yes this is another small reason in favor of having a more beautiful/explicit solution.

@intgr
Copy link
Contributor

intgr commented Dec 31, 2020

It seems this issue will be solved by PEP 613 -- Explicit Type Aliases, mypy issue #9404?

@hauntsaninja
Copy link
Collaborator

Yup!

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

5 participants