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

[Mark Dickinson]

Mark Dickinson  added the comment:

All done, I think. Closing.

--
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Mark Dickinson]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Mark Dickinson]

Change by Mark Dickinson :


--
pull_requests: +26360
pull_request: https://github.com/python/cpython/pull/27902

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Mark Dickinson]

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 `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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Dong-hee Na]

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


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Mark Dickinson]

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


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Serhiy Storchaka]

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, 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).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Dong-hee Na]

Change by Dong-hee Na :


--
pull_requests: +26359
pull_request: https://github.com/python/cpython/pull/27901

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Guido van Rossum]

Guido van Rossum  added the comment:

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

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Dong-hee Na]

Dong-hee Na  added the comment:

@guido

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

IMHO, supporting is reasonable.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Guido van Rossum]

Guido van Rossum  added the comment:

What about __bytes__?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Mark Dickinson]

Change by Mark Dickinson :


--
keywords: +patch
pull_requests: +26341
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/27887

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Mark Dickinson]

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 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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Mark Dickinson]

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__`.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Dong-hee Na]

Change by Dong-hee Na :


--
nosy: +corona10

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Guido van Rossum]

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 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.

--
versions: +Python 3.11 -Python 3.5

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Ethan Smith]

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 this if it would be accepted.

--
nosy: +ethan smith

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Takumi Kato]

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.

--
nosy: +gyu-don

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Mark Dickinson]

Change by Mark Dickinson :


--
nosy: +mark.dickinson

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Guido van Rossum]

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 
enables other code to be more regular, without having to test for the special 
cases.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Serhiy Storchaka]

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 __int__ 
and __float__ is much faster.

--
nosy: +serhiy.storchaka

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Terry J. Reedy]

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) 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.

--
nosy: +terry.reedy

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24234
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Guido van Rossum]

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 up in the context of PEP 484: 
https://github.com/ambv/typehinting/issues/68#issuecomment-88130156 )

--
messages: 243538
nosy: gvanrossum
priority: normal
severity: normal
status: open
title: Should we define complex.__complex__ and bytes.__bytes__?
versions: Python 3.5

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24234
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com