Robert Bradshaw, 03.12.2010 21:03: > My inclination would be to have complex be a simple alias for complex > double, and if one wants the Python object type one can cimport it > from cpython. -1 to having complex be a Python object in the builtin > namespace, or some hybrid object that's a complex double under the > hood but has the (incomplete?) semantics of a complex object. In this > respect the Python complex object type would be like the Python long, > float, and int types. They're rarely what the user actually wants > anyways.
Changes are here: http://hg.cython.org/cython-devel/rev/e9e285544bf2 http://hg.cython.org/cython-devel/rev/06e29edc9f59 I'm not completely happy with the redeclaration of the type in cpython/complex.pxd. These things are always clumsy and also kill a couple of optimisations. Then again, the best optimisation is to not import the type from there in the first place... One thing to note about code like this: def dostuff(complex x): # ... Before, it simply checked the type of the input value and rejected any non-complex objects. Now, it converts the input to a C complex value before it extracts its real/imag parts. This means that it will accept more input types, basically everything that Python can coerce to complex. Likely not a drawback, but who knows what user code looks like... Stefan _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
