On Sun, Oct 21, 2012 at 6:26 AM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote: > I think I've changed my mind on this, since it was pointed > out that if you're going to return a float instead of a > complex, you should really be implementing __float__, not > __complex__. Yes, I'm wavering on this, too. I'm reasonably convinced that the complex constructor is wrong to accept a float return from __complex__. But it's not clear to me whether it's better to break backwards compatibility by fixing that in 3.4, or to accept the mistake and make cmath behave analogously. > Also PyComplex_AsComplex() should perhaps enforce that. It already does. `complex_new` doesn't use `PyComplex_AsCComplex`. -- Mark
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