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
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
