"cdef double a[10]" currently being legal is a good point. I consider myself beaten :-) (my argument from language complexity doesn't hold)
Just keep the feature away from introductory tutorials for numerical programmers :-) I see lots of premature optimization coming from that; and NumPy definitely doesn't have overhead that's not O(1) within the function scope. Robert wrote: > In my mind, arrays are primitive enough that perhaps syntactic sugar should be developed, e.g. > cdef double[] a = cdef double[size] I like Brian's proposal better. This throws in all kind of questions about what kind of allocation semantics Cython really has. Currently one has two ways of variable allocation: i) "stack" (real or emulated); without assignments, ii) Python refcounted object construction with assignment to reference. What exactly is the above? The matter of Cython object allocation is confused enough as it is; in my opinion there already is a problem and one shouldn't make it worse. Simple demonstration: a) For instance, consider the type name being used for constructing objects in Python as well as specifying variable type in Cython. "int" means completely different things depending on the context! (And is really not a name collision issue, "numpy.ndarray" will also come to mean different things depending on context, or at least "c_numpy.ndarray" vs. "numpy.ndarray" which is hardly any better.) b) This mixture of models means that somebody coming from C++ might expect to be able to do cdef list x x.append(10) c) While somebody from a Python background will expect to be able to do: cdef int x[10] = ... cdef int y[10] = x ...and so on... (well, we might be able to fix c). My assertion here is that Cython is already a bit difficult to learn properly! (Meaning it doesn't get into the fingers as much as a more consistent, well thought through language does as Python or C++ or Java). I don't say we should solve this here and now (or even that it can be solved), I just say that all this means that real changes in this area should come after the current model has been evaluated and all the problems with intuivity that is already present has been discussed. That is however a discussion probably better left for after we have full Python support and one starts looking at type inference. (But as "cdef double a[10]" is already valid, allowing "cdef double a[n]" isn't really a change anyway, and so one can just go ahead). Stefan wrote: > BTW, do we actually support cdef's inside blocks? > No, I forgot. That was one of the first things that surprised me when starting to use Cython, it would be nice to have that (any philosophical reasons against it, or just that it was simpler to implement?) Dag Sverre _______________________________________________ Cython-dev mailing list Cython-dev@codespeak.net http://codespeak.net/mailman/listinfo/cython-dev
