This is NOT yet discussed on the Cython list; I wanted to check with more numerical users to see if the issue should even be brought up there. The idea behind the current syntax was to keep things as close as possible to Python/NumPy, and only provide some "hints" to Cython for optimization. My problem with this now is that a) it's too easy to get non-optimized code without a warning by letting in untyped indices, b) I think the whole thing is a bit too "magic" and that it is too unclear what is going on to newcomers (though I'm guessing there). My proposal: Introduce an explicit "buffer syntax": arr = np.zeros(..) cdef int[:,:] buf = arr # 2D buffer Here, buf would be something else than arr; it is a seperate view to the array for low-level purposes. This has certain disadvantages; consider: a1 = np.zeros(...) + 1; a2 = np.zeros(...) + 2 cdef int[:] b1 = a1, b2 = a2 Here, one would need to use b1 and b2 for for-loop arithmetic, but a1 and a2 for vectorized operations and slicing. "b1 + b2" would mean something else and not-NumPy-related (at first disallowed, but see below). "print b1" would likely coerce b1 to a Python memoryview and print "<memoryview ...>" (at least on newer Python versions); one would need to use some function to get b1 back to a NumPy array. Advantages: - More explicit - Leaves a path open in the syntax for introducing low-level slicing and arithmetic as seperate operations in Cython independent of NumPy (think Numexpr compile-time folded into Cython code). - Possible to have some creative syntax like "int[0:]" for disallowing negative wraparound and perhaps even "int[-3:]" for non-zero-based indexing. More details: http://wiki.cython.org/enhancements/buffersyntax (Of course, compatability with existing code will be taken seriously no matter how this plays out!) -- Dag Sverre