> I kinda like the idea of having two types that are only really
> different in corner cases like these, e.g. cint , clong, (maybe int,
> long), and that these are an explicit request for c semantics in every
> way. Other types like int (maybe py_int?) are a request for python
> sematics, even if it means a slight speed penalty over c semantics.
> Making this distinction explicit would seem to make everyone happy
There is a big source of inconsistency here. First, there is no such thing
as an unsigned Python int, a Python char or a Python short. There is no
such thing as a Python pointer. And a Python float is a C double, and a C
float does not exist in Python.
What should this mean?
cdef unsigned int a, b, c
cdef char *a, b # C char, Python bytes, Python string?
# a signed Python int that holds a pointer?
cdef float a, b # single or double precision? who can tell?
cdef double a
cdef short b
cdef long c # what's this? a Python 2 long? a C long?
# C long in Python 3 and Python long in 2.5?
cdef bytes c # Python 3 bytes, C typedef, whatever?
cdef dict d # a dict right? or a ctypedef perhaps?
Explicitely declaring Python types is fine. But then this should be
restricted to actual Python types! Not try to make 25% of C types
Python-like, and leve the rest to behave as in C. Now we get a complete
mess of C and Python semantics, never knowing what we get. There should be
a clear distinction between Python objects and primitive C types.
Further, Python as an official way to make type annotation. If Cython
wants to be as Python-like as possible, use the f*cking Python 3 type
annotations - don't use cdefs.
Making a statically typed Python and braking C is very different. And the
Cython team is breaking C.
Sturla Molden
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
