Decide what to do with numbers.Integral etc.

[JukkaL]

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:

1. Should int be a subclass of Integral (and similarly for float / Real)? If yes, how should we annotate the stubs? (Let's focus on __add__ and __radd__ -- other operators are probably similar.)
2. Should stubs prefer Integral and Real to int and float whenever feasible? Many stdlib functions only accept concrete int or float instances, so using them everywhere wouldn't be safe.
3. Should we recommend user code to use int or Integral by default? If we don't have a consistent convention, integrating codebases that use different conventions could become painful, as Integral should almost certainly not be a subtype of int.
4. Can we find examples of some typical use cases where just using int / float is not sufficient and Integral / Real could help? How common and important are these use cases?
5. If (1) is blocked by limitations of the type system, should we look at extending to the type system to better support abstract numeric types? What are the current limitations?
6. If (1) or (2) requires compromising some type safety, are the gains important enough to make this a worthwhile tradeoff?

[srittau]

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.