[issue24234] Should we define complex.__complex__ and bytes.__bytes__?

Mark Dickinson added the comment: All done, I think. Closing. -- stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue24234] Should we define complex.__complex__ and bytes.__bytes__?

Mark Dickinson added the comment: We've got some buildbot failures; GH-27902 should fix them. Apologies for not catching this while reviewing GH-27901. -- ___ Python tracker

[issue24234] Should we define complex.__complex__ and bytes.__bytes__?

Change by Mark Dickinson : -- pull_requests: +26360 pull_request: https://github.com/python/cpython/pull/27902 ___ Python tracker ___

[issue24234] Should we define complex.__complex__ and bytes.__bytes__?

Mark Dickinson added the comment: > 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

[issue24234] Should we define complex.__complex__ and bytes.__bytes__?

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

[issue24234] Should we define complex.__complex__ and bytes.__bytes__?

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

[issue24234] Should we define complex.__complex__ and bytes.__bytes__?

Serhiy Storchaka added the comment: 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,

[issue24234] Should we define complex.__complex__ and bytes.__bytes__?

Change by Dong-hee Na : -- pull_requests: +26359 pull_request: https://github.com/python/cpython/pull/27901 ___ Python tracker ___

[issue24234] Should we define complex.__complex__ and bytes.__bytes__?

Guido van Rossum added the comment: So let’s add that in a separate PR. -- --Guido (mobile) -- ___ Python tracker ___ ___

[issue24234] Should we define complex.__complex__ and bytes.__bytes__?

Dong-hee Na added the comment: @guido >>> issubclass(bytes, typing.SupportsBytes) False IMHO, supporting is reasonable. -- ___ Python tracker ___

[issue24234] Should we define complex.__complex__ and bytes.__bytes__?

Guido van Rossum added the comment: What about __bytes__? -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue24234] Should we define complex.__complex__ and bytes.__bytes__?

Change by Mark Dickinson : -- keywords: +patch pull_requests: +26341 stage: -> patch review pull_request: https://github.com/python/cpython/pull/27887 ___ Python tracker ___

[issue24234] Should we define complex.__complex__ and bytes.__bytes__?

Mark Dickinson added the comment: > [...] 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

[issue24234] Should we define complex.__complex__ and bytes.__bytes__?

Mark Dickinson added the comment: 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__`. --

[issue24234] Should we define complex.__complex__ and bytes.__bytes__?

Change by Dong-hee Na : -- nosy: +corona10 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue24234] Should we define complex.__complex__ and bytes.__bytes__?

Guido van Rossum added the comment: 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

[issue24234] Should we define complex.__complex__ and bytes.__bytes__?

Ethan Smith added the comment: 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

[issue24234] Should we define complex.__complex__ and bytes.__bytes__?

Takumi Kato added the comment: 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. --

[issue24234] Should we define complex.__complex__ and bytes.__bytes__?

Change by Mark Dickinson : -- nosy: +mark.dickinson ___ Python tracker ___ ___

[issue24234] Should we define complex.__complex__ and bytes.__bytes__?

Guido van Rossum added the comment: 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

[issue24234] Should we define complex.__complex__ and bytes.__bytes__?

Serhiy Storchaka added the comment: 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

[issue24234] Should we define complex.__complex__ and bytes.__bytes__?

Terry J. Reedy added the comment: 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)

[issue24234] Should we define complex.__complex__ and bytes.__bytes__?

New submission from Guido van Rossum: 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