Robert Bradshaw, 03.12.2010 20:20: > On Fri, Dec 3, 2010 at 11:13 AM, Stefan Behnel wrote: >> Dag Sverre Seljebotn, 03.12.2010 20:04: >>> I do have a much bigger problem with the naming here. I find >>> this very little user-friendly: >>> >>> cdef complex x # x is Python object >>> cdef double complex x # same precision but in C >>> cdef float complex x # single precision in C >>> >>> I really do feel that "int" has kind of set the precedent here, and that >>> if only "complex" is made available it should be as "double complex" or >>> similar. >> >> I would argue that the precendent is actually "float". We already (safely) >> alias Python's "float" type to C's "double" type. Doing the same thing for >> "complex" won't hurt as long as it keeps the same interface, would it? > > If I write > > cdef float x > > there's no Python float object in the picture at all.
Come on, it's almost Christmas. Could we please all get back to understanding each other? ;) I meant: we alias floating point values to C doubles and infer "double" even if we know it's actually a Python float. When we do the same thing for complex values and alias them to "C complex", we won't loose anything. > If we have > complex as a builtin type name, I would rather it be a double complex, > not a complex object. +1 (*wink*) > BTW, I find this bothersome: > > cdef float x > x.foo() > > I'd much rather that raise a compile time error, but that's somewhat > orthogonal. This should keep working, though: >>> 1. .conjugate() 1.0 i.e. cdef double x = 1.0, y y = x.conjugate() should behave as in Python. Same for unbound methods, for example. But I wouldn't mind getting an error for unknown attributes, such as your "foo" above. After all, it's clear at compile time that this won't work at runtime (assuming that there won't be a new Python major release in the meantime ...). Stefan _______________________________________________ Cython-dev mailing list Cython-dev@codespeak.net http://codespeak.net/mailman/listinfo/cython-dev