SupportsComplex and SupportsBytes?

[JukkaL]

Similar to SupportsInt and SupportsFloat, should typing define SupportsComplex and SupportsBytes?

For example:

from typing import SupportsBytes

class A(SupportsBytes):
    def __bytes__(self):
        return b'foo'

bytes(A())  # ok!

[gvanrossum]

I'm lukewarm. I haven't really followed the use cases for SupportsInt. Also, is there a deep difference between these and collection.abc's Hashable, Iterable, Iterator, Sized, Container, which represent similar ideas but with one-off implementations? (And am I the only one confused by the fact that most of the SupportsXXX classes are named after a built-in type?)

[JukkaL]

There is no deep difference -- they are similar to Sized. SupportsXxx means that the type can be passed to xxx(). For example, SupportsInt means that you can pass the value to int() (i.e., it defines __int__).

If we didn't have those types, how would we specify that Decimal is a valid argument to int()? We'd have to use something like d.__int__() (if d has type Decimal) or a cast, both of which would be pretty ugly. On the other hand, there aren't that many types that can be passed to int(), so maybe that wouldn't be a big problem. Alternatively, we could allow any argument types to int, even those that would cause the call to fail at runtime.

If we supported structural subtyping, we could easily just define internal, anonymous structural types for these functions and not expose them at all in typing. We can actually still kind of do that even without structural subtyping -- we could define types such as _SupportsInt internally and use them within our stubs (for things like Decimal), but we wouldn't allow user-defined classes to add support for int().

I'm not attached to the naming of these types -- if I remember correctly, it was you who proposed this convention :-) I can't think of a good name similar to Sized for something that can be passed to int(). We could have something like Roundable for something that can be passed to round().

[gvanrossum]

OK, I think it's fine to add a few more, I'll add bytes and complex. If we find we need a lot more of these we should rethink this though.

[gvanrossum]

Closed by revision a8cd08d. However, I noticed that complex.__complex__ and bytes.__bytes__ don't exist. (Unlike int.__int__, float.__float__, which do exist.)

[gvanrossum]

I filed http://bugs.python.org/issue24234 for the issue about eponymous methods.