On 20/10/12 01:13, Nick Coghlan wrote: > On Fri, Oct 19, 2012 at 11:08 PM, Antonio Cuni<anto.cuni at gmail.com> wrote: >> Is that the real intended behavior? > > Given the way complex numbers interact with floats generally, > returning a complex number with no imaginary component as a floating > point value seems legitimate Surely the intention is for __complex__ to return a complex number? That is, that it is desirable to have the invariant: isinstance(x.__complex__(), complex) ? We expect that __int__ returns an int, and raise an exception if it doesn't, even in the case that the value returned is numerically integral: py> class X: ... def __int__(self): ... return 2.0 ... py> x = X() py> int(x) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: __int__ returned non-int (type float) Conceptually, I see returning a float when you expect a complex as equally dubious as returning an integral float when you expect an int. I think there is something dirty about a __complex__ that returns a non-complex. Why would you deliberately do such a thing? If a class does so, that's surely indicative of a bug, so the earlier it gets caught, the better. > and the checks in cmath overly strict. > > Otherwise you would get redundancy like: > > def __complex__(self): > return complex(value) > or > > def __complex__(self): > return value + 0j For the record, I think Nick is referring to the fact that the complex constructor will fall back on __float__ if __complex__ does not exist, adding 0j to x.__float__. I don't see this as a problem. So what if people write redundant code? It still works. And when they learn better, they can write better code. -- Steven
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4