On Sat, Dec 4, 2010 at 2:24 AM, Stefan Behnel <[email protected]> wrote: > 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
Thanks. > 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... Yep. > 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... I think it'll be pretty safe. - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
