Static typing for Ellipsis
Currently, there's no PEP 484 way to type an Ellipsis, making it hard to add type checking to getitem/setitem. Type checkers (like MyPy, and it appears PyType) have supported "ellipsis" (as a string) as a stand-in for the missing type. This breaks linters like pyflakes, which expect "ellipsis" to be imported from somewhere even when it's a string, since it's not a builtin. (It MyPy's case, it also doesn't participate in narrowing, for some reason). It's also very difficult to discover. It seems the most user-friendly solution would be to add a special case for Ellipsis, just like there is one for None (and NotImplemented might be due such a special case, too, based on the original thread from last year which I hope is linked in here). MyPy clearly differentiates between "..." and "Ellipsis" now; tuple[int, Ellipsis] does not work as a stand-in for tuple[int, ...]. Like None, there is only one Ellipsis, and it does not have an accessible base type. If there's a problem with that solution, then adding "ellipsis" to typing would be a second possible solution. Then the name is correctly importable, and a bit more discoverable than a type-checker-only name. But IMO this should only be used if absolutely impossible to implement the first solution. See also the issue in pyflakes: https://github.com/PyCQA/pyflakes/issues/616 with a couple of examples.
What about adding `EllipsisType` to the `types <https://docs.python.org/3/library/types.html>` std lib? This is how we handle types for modules and so on. On the other hand, I'm not sure if Ellipsis counts as an "interpreter type" like the rest of the `types` lib. It seems closer to None, in the sense that it's a singleton, as you said. Also, shouldn't `...` and `Ellipsis` be equivalent? My understanding is that they are synonyms, so I'm surprised that mypy doesn't treat them the same. -- Teddy On Wed, Mar 10, 2021 at 11:37 AM <henryfs@princeton.edu> wrote:
Currently, there's no PEP 484 way to type an Ellipsis, making it hard to add type checking to getitem/setitem. Type checkers (like MyPy, and it appears PyType) have supported "ellipsis" (as a string) as a stand-in for the missing type. This breaks linters like pyflakes, which expect "ellipsis" to be imported from somewhere even when it's a string, since it's not a builtin. (It MyPy's case, it also doesn't participate in narrowing, for some reason). It's also very difficult to discover.
It seems the most user-friendly solution would be to add a special case for Ellipsis, just like there is one for None (and NotImplemented might be due such a special case, too, based on the original thread from last year which I hope is linked in here). MyPy clearly differentiates between "..." and "Ellipsis" now; tuple[int, Ellipsis] does not work as a stand-in for tuple[int, ...]. Like None, there is only one Ellipsis, and it does not have an accessible base type.
If there's a problem with that solution, then adding "ellipsis" to typing would be a second possible solution. Then the name is correctly importable, and a bit more discoverable than a type-checker-only name. But IMO this should only be used if absolutely impossible to implement the first solution.
See also the issue in pyflakes: https://github.com/PyCQA/pyflakes/issues/616 with a couple of examples. _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: tsudol@google.com
The reason `ellipsis` works in mypy is that we put it in `builtins.pyi` in typeshed that way: https://github.com/python/typeshed/blob/master/stdlib/builtins.pyi#L1260. Using it with `if TYPE_CHECKING: from builtins import ellipsis` should work and may silence your linter. Of course this is still obscure and hard to discover. Making `Ellipsis` (and `NotImplemented`, while we're at it) work like `None` is an appealing solution. If all the type checker authors agree, we could specify that with a small update to PEP 484. It's important that Ellipsis and `...` are not synonyms, so that `Tuple[str, ...]` continues to mean a tuple of arbitrarily many strings, not a tuple or a string and an Ellipsis. El mié, 10 mar 2021 a las 11:53, Teddy Sudol via Typing-sig (< typing-sig@python.org>) escribió:
What about adding `EllipsisType` to the `types <https://docs.python.org/3/library/types.html>` std lib? This is how we handle types for modules and so on. On the other hand, I'm not sure if Ellipsis counts as an "interpreter type" like the rest of the `types` lib. It seems closer to None, in the sense that it's a singleton, as you said.
Also, shouldn't `...` and `Ellipsis` be equivalent? My understanding is that they are synonyms, so I'm surprised that mypy doesn't treat them the same.
-- Teddy
On Wed, Mar 10, 2021 at 11:37 AM <henryfs@princeton.edu> wrote:
Currently, there's no PEP 484 way to type an Ellipsis, making it hard to add type checking to getitem/setitem. Type checkers (like MyPy, and it appears PyType) have supported "ellipsis" (as a string) as a stand-in for the missing type. This breaks linters like pyflakes, which expect "ellipsis" to be imported from somewhere even when it's a string, since it's not a builtin. (It MyPy's case, it also doesn't participate in narrowing, for some reason). It's also very difficult to discover.
It seems the most user-friendly solution would be to add a special case for Ellipsis, just like there is one for None (and NotImplemented might be due such a special case, too, based on the original thread from last year which I hope is linked in here). MyPy clearly differentiates between "..." and "Ellipsis" now; tuple[int, Ellipsis] does not work as a stand-in for tuple[int, ...]. Like None, there is only one Ellipsis, and it does not have an accessible base type.
If there's a problem with that solution, then adding "ellipsis" to typing would be a second possible solution. Then the name is correctly importable, and a bit more discoverable than a type-checker-only name. But IMO this should only be used if absolutely impossible to implement the first solution.
See also the issue in pyflakes: https://github.com/PyCQA/pyflakes/issues/616 with a couple of examples. _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: tsudol@google.com
_______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: jelle.zijlstra@gmail.com
+1 On Wed, Mar 10, 2021 at 12:32 PM Jelle Zijlstra <jelle.zijlstra@gmail.com> wrote:
The reason `ellipsis` works in mypy is that we put it in `builtins.pyi` in typeshed that way: https://github.com/python/typeshed/blob/master/stdlib/builtins.pyi#L1260. Using it with `if TYPE_CHECKING: from builtins import ellipsis` should work and may silence your linter.
Of course this is still obscure and hard to discover. Making `Ellipsis` (and `NotImplemented`, while we're at it) work like `None` is an appealing solution. If all the type checker authors agree, we could specify that with a small update to PEP 484.
It's important that Ellipsis and `...` are not synonyms, so that `Tuple[str, ...]` continues to mean a tuple of arbitrarily many strings, not a tuple or a string and an Ellipsis.
El mié, 10 mar 2021 a las 11:53, Teddy Sudol via Typing-sig (< typing-sig@python.org>) escribió:
What about adding `EllipsisType` to the `types <https://docs.python.org/3/library/types.html>` std lib? This is how we handle types for modules and so on. On the other hand, I'm not sure if Ellipsis counts as an "interpreter type" like the rest of the `types` lib. It seems closer to None, in the sense that it's a singleton, as you said.
Also, shouldn't `...` and `Ellipsis` be equivalent? My understanding is that they are synonyms, so I'm surprised that mypy doesn't treat them the same.
-- Teddy
On Wed, Mar 10, 2021 at 11:37 AM <henryfs@princeton.edu> wrote:
Currently, there's no PEP 484 way to type an Ellipsis, making it hard to add type checking to getitem/setitem. Type checkers (like MyPy, and it appears PyType) have supported "ellipsis" (as a string) as a stand-in for the missing type. This breaks linters like pyflakes, which expect "ellipsis" to be imported from somewhere even when it's a string, since it's not a builtin. (It MyPy's case, it also doesn't participate in narrowing, for some reason). It's also very difficult to discover.
It seems the most user-friendly solution would be to add a special case for Ellipsis, just like there is one for None (and NotImplemented might be due such a special case, too, based on the original thread from last year which I hope is linked in here). MyPy clearly differentiates between "..." and "Ellipsis" now; tuple[int, Ellipsis] does not work as a stand-in for tuple[int, ...]. Like None, there is only one Ellipsis, and it does not have an accessible base type.
If there's a problem with that solution, then adding "ellipsis" to typing would be a second possible solution. Then the name is correctly importable, and a bit more discoverable than a type-checker-only name. But IMO this should only be used if absolutely impossible to implement the first solution.
See also the issue in pyflakes: https://github.com/PyCQA/pyflakes/issues/616 with a couple of examples. _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: tsudol@google.com
_______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: jelle.zijlstra@gmail.com
_______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: guido@python.org
-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
participants (4)
-
Guido van Rossum -
henryfs＠princeton.edu -
Jelle Zijlstra -
Teddy Sudol