Please use int and float instead of numbers.Integral/Real

[gvanrossum]

PEP 484 intentionally recommends using int/float instead of the numeric ABCs, and mypy doesn't like them at all:

from numbers import Integral, Real
def f(i: Integral, x: Real) -> Real:
    return i * x
f(1, 3.14)

gives these errors:

__tmp__.py:4: error: Argument 1 to "f" has incompatible type "int"; expected "Integral"
__tmp__.py:4: error: Argument 2 to "f" has incompatible type "float"; expected "Real"

[posita]

Just to be clear, we're talking about The Numeric Tower, correct? From that section:

[Limiting one's numeric typing use to float and int] does not handle classes implementing the corresponding ABCs or the fractions.Fraction class, but we believe those use cases are exceedingly rare.

Probably not relevant to this issue, but what is that belief based on? Also, I'm curious why have ABCs at all, if they're not useful for exactly this kind of thing?

[gvanrossum]

Yes, that's the section I'm talking about.

It's not ABCs in general that are useless (to the contrary, witness mypy's encouragement of using e.g. Iterable, Mapping etc.), just the ABCs for numbers. There are very few reasons to implement your own numeric types from scratch, since the built-in ones are really pretty good; the only popular alternative numeric type that I know of, Decimal, explicitly doesn't follow the numeric ABCs (there's a note in numbers.py explaining why).

I suppose numpy also counts as popular alternate number implementation, and they do support PEP 3141. But I don't know how much people use that fact. Certainly numpy's own code has very few mentions of the numbers module, and I could not find any mention of it in the numpy docs.

Personally I think PEP 3141 is a dead end. Very few people import the numbers module to use with isinstance() or issubclass() and even fewer use it to implement their own numeric types; and very few people writing numeric code care whether their code works for numbers that aren't instances of the concrete classes they themselves use regularly.

If you really believe that Stone has important uses for numpy numbers in annotations then maybe we need to talk (we could have a look at what it takes to make int and float subclasses of numbers.Integral/Real in typeshed, or we could look at support for ABC.register()). But so far we're really just talking about the minimum and maximum fields of Stone's own bounded integer and real types, I think using plain old int and float is totally fine.

[posita]

If you really believe that Stone has important uses for numpy numbers in annotations then maybe we need to talk …

I'm not sure I have an example in mind that isn't solved by some kind of "casting" before use. (Even Python-Future's int subclasses long.)

Personally I think PEP 3141 is a dead end. Very few people import the numbers module to use with isinstance() or issubclass() and even fewer use it to implement their own numeric types; and very few people writing numeric code care whether their code works for numbers that aren't instances of the concrete classes they themselves use regularly.

Perhaps I am being (overly) nervous as a "purist"? Other than PEP 484, I can't find any official suggestion that PEP 3141 should be avoided or treated as deprecated. True, its use is probably rare, or an afterthought, but it just feels dirty that type checking should ever be incompatible with ABCs. But maybe I'll just up my dose of Sertraline and move on. 😏

(Referencing python/mypy#2636 for background.)

[gvanrossum]

Python isn't a safe place for purists. :-) I don't think there's an official statement of any sort about PEP 484, it's just my hunch that it's not as important as it was thought to be when it was accepted.

[zero323]

@gvanrossum Is this really a hunch about PEP 484? If so you're crashing my dreams... :-)

[gvanrossum]

Too bad. ;-P

[zero323]

Not a bit of compassion here :-) To be serious - should it be limited to numbers?

from collections.abc import Hashable

def f(x: Hashable) -> int:
    return hash(x)

f("foo")

gives

test_abc.py:6: error: Argument 1 to "f" has incompatible type "str"; expected "Hashable"

[gvanrossum]

Yes, this is just about numbers. For Hashable the right solution is to fix typeshed.

…

--Guido (mobile)

On Feb 8, 2017 1:51 PM, "Maciej Szymkiewicz" ***@***.***> wrote: Not a bit of compassion here :-) To be serious - should it be limited to numbers? from collections.abc import Hashable def f(x: Hashable) -> int: return hash(x) f("foo") gives test_abc.py:6: error: Argument 1 to "f" has incompatible type "str"; expected "Hashable" — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#33 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACwrMiBBF8KI3xAeI8F22qb6AK5he44Fks5rajjTgaJpZM4La-MY> .

[zero323]

Thanks @gvanrossum.