Should int be compatible with float and mypy's @ducktype decorator about typing HOT 6 CLOSED

There's also the number module which defines ABCs corresponding to complex, float, int (named Complex, Real, Integral -- this was introduced in PEP 3141). So while int isn't a subclass of float, it's a subclass of number.Real. And we worked hard in Python 3 to make sure that an int is always acceptable where a float is expected, and an int or float is acceptable where a complex is expected. (This is why int division changed!) IOW I agree that we should somehow make sure that the type checker supports this. And I think it's acceptable despite the lack of int.hex(). (Maybe it's a bug?)

I'm not sure that @ducktype is the right term, but I'm out of imagination. I think it should only be supported in stub modules. I think UserString is a losing proposition; the 3.x docs say it's deprecated. I'm not sure what to do about mocks -- they seem to open a whole different can of worms that I'd rather keep closed.

from typing.

I think there's a very limited set of such relationships that isn't extensible, so maybe instead of an extensible feature like @ducktype there should just be a hardcoded set of rules, at least in 3.5:

• Numbers can be promoted up the tower (int for float, float for complex).
• A bytearray can be used as a bytes (and maybe a set as a frozenset?).

Are there any other such cases? Is there any reason a third-party library might want to add any?

If you do want such a feature, maybe @promote or something similar is a better name. After all, the paradigm case is C-style automatic numeric promotion. (For the other two potential cases, I think there is actually a clear subtype relationship, even if it isn't reflected in the language.)

from typing.

I recently removed mypy's @ducktype decorator (at least from the public interface), and replaced it with a hard coded set of promotions (int -> float and float -> complex).

What about promoting from bytearray to bytes, as mentioned by @abarnert ? This wouldn't be generally valid, esp. for C modules (e.g., os.path.join doesn't accept bytearray arguments), but we might still want it.

Another similar issue is int -> decimal.Decimal. Mypy currently requires using something like Union[Decimal, int] (potentially with a type alias) to support this. This case may be rare enough that using a union may be a reasonable solution for this.

from typing.

I like promoting from bytearray to bytes; can we also promote from memoryview to bytes? Maybe we can even fix os.path.join()?

I propose not to bother with Decimal -- it intentionally (if awkwardly) lives outside the numeric tower defined by PEP 3141. We'll see if the users push back.

from typing.

For what it's worth, I found it surprising that when I created a dataclass like:

@dataclass(frozen=True)
class Position:
    x: float
    y: float

mypy didn't catch this typo I made:

p = Position(0.0, 0)

from typing.

@johnthagen mypy considers int a subclass of float. You can read about it in PEP 484. Most people would consider this correct.

from typing.