Skip to content

Literal types tracking issue #5935

Closed
Closed
@Michael0x2a

Description

@Michael0x2a

This issue tracks TODOs for literal types.

Core work

Parsing/semantic analysis follow-up tasks

Error messages

Implementing and testing type visitors

Implement and write tests that exercise the following visitors. (Introduced by #5934)

The following have preliminary implementations, but are missing associated tests:

Other checks to add in the type-checking layer

  • Make sure we cannot subclass Literals (Prohibit some illegal uses of Literal #6034)
  • Blacklist constructs like Type[Literal[4]]
    • Actually, should we? Maybe we should treat Type[Literal[4]] as int instead -- this might make certain TypeVar shenanigans more smooth. Need to discuss.
    • Actually, the above idea seems like a bad idea: if we do x: Literal[3], doing type(x) ought to return a value with type Type[int], not just int.
  • Blacklist using Literal[...] in isinstance and issubclass checks (Prohibit some illegal uses of Literal #6034)
  • Validate Literal works as expected when used in generics (Add tests for literals and generics #6035)
  • Consider having mypy warn if somebody tries doing literally TypeVar('T', bound=Literal[4])? Need to discuss first.

"Extra" features to add

Things to do before mypy 0.660 is released if literal types aren't going to make it

Other things

  • Try replacing one of the functions we currently manage using plugins with literal types instead, and see what happens.
    • I tried replacing the "open(...)" plugin and re-ran mypy on one of our smaller internal codebases. Out of approximately 680 calls to open, about 610 of them had 2 or more arguments. We inferred the correct type for about 560 of those. About another 20 of these were passing in string variable arguments as the mode. The remaining 30 require a little more investigation -- some people were passing in **kwargs or **args in as the argument, etc...

Things that have been deferred to after this project is completed

  • Adding support for enums in literal types (and while I'm at it, I might as well investigate overhauling enums in general). Related tasks:
    • Treat enum classes as roughly a union of their values
    • Better error messages for bad imports (e.g. enums with a coerced type of 'Any')
  • In error messages, we seem to quote types using either single quotes or double quotes. This can sometimes lead to messy-looking error messages (e.g. Revealed type is 'Literal['foo']'). We should standardize on a specific quoting scheme + avoid this weird "nesting" issue.
  • Make sure we report an error when somebody tries doing Literal[3]() (and Final[int]() and Protocol[blah]()...)

Metadata

Metadata

Assignees

Labels

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions