-
Notifications
You must be signed in to change notification settings - Fork 234
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
Decide what to do with numbers.Integral etc. #272
Labels
topic: feature
Discussions about new features for Python's type annotations
Comments
srittau
added
the
topic: feature
Discussions about new features for Python's type annotations
label
Nov 4, 2021
As this issue has been open for more than five years, asks questions, but has no discussion, I am going to close this. The numbers hierarchy is still an open question, but I think we are better served at this point with concrete suggestions than to keep this open. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
It's not clear what's the best way to deal with
numbers.Integral
,numbers.Real
, etc. Various issues are discussed in python/typeshed#464.Some relevant questions:
int
be a subclass ofIntegral
(and similarly forfloat
/Real
)? If yes, how should we annotate the stubs? (Let's focus on__add__
and__radd__
-- other operators are probably similar.)Integral
andReal
toint
andfloat
whenever feasible? Many stdlib functions only accept concreteint
orfloat
instances, so using them everywhere wouldn't be safe.int
orIntegral
by default? If we don't have a consistent convention, integrating codebases that use different conventions could become painful, asIntegral
should almost certainly not be a subtype ofint
.int
/float
is not sufficient andIntegral
/Real
could help? How common and important are these use cases?The text was updated successfully, but these errors were encountered: