Repository navigation
special rules in typeshed pyi #270
Description
Let's use this issue to track special stub rules that found their way into typeshed stubs. Since mypy is currently the only system used for testing typeshed, it's natural for some mypy logic to become reflected in the typeshed stubs.
So far I have:
- When something is declared as taking unicode (in the PY2 stubs) then it actually also takes str/bytes.
- When something is declared as taking only float, it also takes int. (EDIT: This is mentioned in PEP 484. See https://www.python.org/dev/peps/pep-0484/#the-numeric-tower)
(I'll add these to README.md once we have a complete list.)
Activity
matthiaskramm commentedon Jul 7, 2016
smontanaro commentedon Jul 7, 2016
Is int <-> long implicit, or does everywhere I have "int" need to be changed to "Union[int, long]"?
matthiaskramm commentedon Jul 7, 2016
It's implicit. This whole thread is about things that are implicit. (And the
int <-> longequivalence actually is useful, precisely so that you don't have to useUnion[int, long])matthiaskramm commentedon Aug 22, 2016
bool, it also takesNoneType.JukkaL commentedon Aug 22, 2016
intbeing compatible withfloatis mentioned in PEP 484, so it's not a mypy-specific thing (https://www.python.org/dev/peps/pep-0484/#the-numeric-tower).--strict-optional,Noneis no longer valid whenboolis expected. Currently mypy considersNonealways valid for any type by default, not just forbool. Typeshed should useOptional[...]consistently. I think that providingNonewhenboolis expected should generally be an error (except maybe if that turns out to generate a lot of false positives).matthiaskramm commentedon Aug 22, 2016
Thanks for the clarification! I'll edit the posts above.
That's what pytype used to do. But our internal users were complaining about it, so we now allow None, too. It seems "safe" enough. At least, it's not clear what a false negative would look like. (Maybe a function without a return?)
JukkaL commentedon Aug 23, 2016
Here are some potential cases where
Noneis not valid when expecting abool:FalseandNonewill be encoded differently.FalseandNoneencode differently.str(None)vs.str(False)), perhaps as part of an error message.x == False(yes, they are bad style but they happen).JelleZijlstra commentedon Apr 23, 2017
Is it worth adding the unicode/str and int/long promotions for Python 2.7 to PEP 484? Does pytype behave differently from mypy?
gvanrossum commentedon Apr 23, 2017
I like the idea of specifying promotions in PEP 484. We'd have to have consensus from PyCharm (@vlasovskikh) and pytype (@matthiaskramm).
matthiaskramm commentedon Apr 23, 2017
+1
This should definitely be documented in a more prominent place, instead of in the depths of the typeshed issue tracker.
pytype does the same thing as mypy.
PEP 484: Add implicit promotions for Python 2.7
JelleZijlstra commentedon Apr 24, 2017
python/peps#245
PEP 484: Add implicit promotions for Python 2.7 (#245)
vlasovskikh commentedon Apr 26, 2017
+1. PyCharm already supports these promotions except long -> int.
JelleZijlstra commentedon Apr 4, 2018
All of the examples mentioned here have now been standardized in PEP 484, and we should not be standardizing any other mypy peculiarities in typeshed, so I don't see a reason to keep this open.