The special methods __complex__ and __bytes__ are not present on the corresponding builtin types.  Compare this to __int__ and __float__, which do exist on int and float, respectively.  Should we add the eponymous methods to complex and bytes?

(This came up in the context of PEP 484: https://github.com/ambv/typehinting/issues/68#issuecomment-88130156 )

To my understanding, the presence of int.__int__ and float.__float__ are implementation issues.  I presume that float(ob) just calls ob.__float__ without slowing down for an isinstance(ob, float) check.  Ditto for int(ob).  The processing for complex(args) and bytes(args) are more complex and currently neither call an eponyous method. Would either be improved if it did?

One difference between int and complex, for instance, that might account for the internal implementation difference is that the second argument of int can only be used with a string first argument, while the second argument of complex cannot be used with a string first argument, and must support multiplication by 1j.  So int.__int__(self) does not allow a second parameter and can (and does) just return self.

The difference between __complex__ and __bytes__ on one side, and __int__ and __float__ on other side is that the latter have dedicated type slots while the former are just entries in the type's dict. Thus testing and calling __int__ and __float__ is much faster.

It's not necessary for complex() and bytes() to call the special methods if the argument's type is exactly complex or bytes (respectively) -- these cases are already taken care of by the current code.  But adding these special methods enables other code to be more regular, without having to test for the special cases.

Recently, the situation has changed. We should consider this issue again.

typing.SupportsComplex is an ABC with one abstract method __complex__.
Thus, isinstance(complex, typing.SupportsComplex) is False.
typing.SupportsBytes also.

It is nonsense.

While I don't think it is nonsense, I do think it would be quite useful to add these. I just submitted PRs to typeshed and numpy adding complex to unions that already had SupportsComplex, because of the lack of __complex__. I'd be happy to work on a PR for this if it would be accepted.

Yeah, the more I think about it, the more it looks like we should add the special methods -- even if they won't necessarily be called *if the type is exactly 'complex' or 'bytes'*.

Now, until we've written and released the code we won't know for sure whether this might break somebody's corner case, so we should play it safe and only do this for 3.11 and make sure it's mentioned in the What's New.

If the goal is to have `isinstance(obj, typing.SupportsComplex)` pass for objects that are convertible to complex, then we'll need `int.__complex__` and `float.__complex__` implementations as well as `complex.__complex__`.

> [...] we'll need `int.__complex__` and `float.__complex__` implementations as well as `complex.__complex__`.

The real problem here is that the "typing.SupportsComplex" protocol isn't a good match for code that needs to know that a given value `x` can be treated as though it were a complex number.

The test that best matches "usable as a complex number" seems to be that type(x) implements at least one of `__index__`, `__float__` or `__complex__`, or that `x` is a subclass of complex.

It looks to me as though the right thing to do here is to just implement complex.__complex__, but not int.__complex__ or float.__complex__.  Then at least we can remove the subclass test from the above and express the test purely in terms of special methods: __index__, __float__ and __complex__. And then perhaps it's for the typing module to find a more convenient way to express the union of typing.SupportsIndex, typing.SupportsFloat and typing.SupportsComplex.

What about __bytes__?

@guido

>>> issubclass(bytes, typing.SupportsBytes)
False

IMHO, supporting is reasonable.

So let’s add that in a separate PR.
-- 
--Guido (mobile)

Defining complex.__complex__ and bytes.__bytes__ would not solve anything, because

>>> issubclass(int, SupportsComplex)
False
>>> issubclass(float, SupportsComplex)
False
>>> issubclass(bytearray, SupportsBytes)
False
>>> issubclass(memoryview, SupportsBytes)
False

If SupportsComplex and SupportsBytes are just for "has __complex__/__bytes__ method", they are virtually useless. If their meaning is "can be converted to complex/bytes", it is different story, and it should be fixed be adding subclasshooks which check existence of alternate methods (__float__, __index__, supporting the buffer protocol).

New changeset 6082bb5addab93755ab6e2bd2ed6021b391e10d1 by Mark Dickinson in branch 'main':
bpo-24234: implement complex.__complex__ (GH-27887)
https://github.com/python/cpython/commit/6082bb5addab93755ab6e2bd2ed6021b391e10d1

New changeset 24b63c695ae0a95b06379eaadace66735abac1e2 by Dong-hee Na in branch 'main':
bpo-24234: Implement bytes.__bytes__ (GH-27901)
https://github.com/python/cpython/commit/24b63c695ae0a95b06379eaadace66735abac1e2

> If SupportsComplex and SupportsBytes are just for "has __complex__/__bytes__ method", they are virtually useless.

I agree that "SupportsComplex" isn't directly useful in user-land. I think its main value is as a building block in things like `Union[SupportsComplex, SupportsFloat, SupportsIndex]`.

For me, the gain from implementing complex.__complex__ is that the test "can be used as a complex number" can now be expressed purely in terms of the protocols offered, without reference to concrete types.

We've got some buildbot failures; GH-27902 should fix them. Apologies for not catching this while reviewing GH-27901.

All done, I think. Closing.