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

Prohibit some illegal uses of Literal #6034

Merged
merged 1 commit into from
Dec 9, 2018

Conversation

Michael0x2a
Copy link
Collaborator

This pull request checks to make sure we report errors if the user tries using Literal types in invalid places. In particular, this PR...

  1. Adds tests to make sure we cannot subclass Literals (mypy already directly supported this)
  2. Checks to make sure we cannot use Literals inside isinstance and issubclass checks

I also wanted to add a check preventing people from attempting to instantiate a Literal (e.g. disallow Literal[3]() or Literal()), but that might require a little more work and a few changes to typing_extensions. (We currently don't raise an error when people try doing things like Final(), Final[int]() or Protocol() either).

This pull request checks to make sure we report errors if the user tries
using Literal types in invalid places. In particular, this PR...

1. Adds tests to make sure we cannot subclass Literals (mypy already
   directly supported this)
2. Checks to make sure we cannot use Literals inside `isinstance`
   and `issubclass` checks

I also wanted to add a check preventing people from attempting to
instantiate a Literal (e.g. disallow `Literal[3]()` or `Literal()`),
but that might require a little more work and a few changes to
`typing_extensions`. (We currently don't raise an error when people
try doing things like `Final()`, `Final[int]()` or `Protocol()` either).
@Michael0x2a Michael0x2a mentioned this pull request Dec 8, 2018
42 tasks
@ilevkivskyi
Copy link
Member

(We currently don't raise an error when people try doing things like Final(), Final[int]() or Protocol() either)

Hm, maybe this depend on version, but I see this:

>>> Protocol()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/ivan/mypy_dev/lib/python3.6/site-packages/typing_extensions.py", line 1166, in __new__
    raise TypeError("Type Protocol cannot be instantiated; "
TypeError: Type Protocol cannot be instantiated; it can be used only as a base class
>>> Final()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.6/typing.py", line 194, in __call__
    raise TypeError("Cannot instantiate %r" % type(self))
TypeError: Cannot instantiate typing_extensions.Final
>>> Final[int]()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.6/typing.py", line 194, in __call__
    raise TypeError("Cannot instantiate %r" % type(self))
TypeError: Cannot instantiate typing_extensions.Final

Anyway, I think the fact that the error is emitted at runtime means it is not super-important to also flag this statically.

@Michael0x2a
Copy link
Collaborator Author

(We currently don't raise an error when people try doing things like Final(), Finalint or Protocol() either)

Oh, I meant we don't raise an error at type-check-time. (Well, we sort of do for Final(), Protocol(), and Literal() -- but the error message is just "_SpecialForm not callable", which I imagine would somewhat puzzle users who aren't aware of mypy/typing internals.)

Anyway, I think the fact that the error is emitted at runtime means it is not super-important to also flag this statically.

Yeah -- I agree. I thought about making more of an effort to add support for this, but came to the same conclusion you did and just submitted this PR as-is.

Copy link
Member

@ilevkivskyi ilevkivskyi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! LGTM.

@Michael0x2a Michael0x2a merged commit dcfebd7 into python:master Dec 9, 2018
@Michael0x2a Michael0x2a deleted the prohibit-bad-use-of-literal branch December 9, 2018 21:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants