[Numpy-discussion] Cython numerical syntax revisited

Andrew Straw strawman@astraw....
Wed Mar 4 17:08:09 CST 2009

Dag Sverre Seljebotn wrote:
> 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).

These may be issues, but I think keeping "cython -a my_module.pyx" in 
one's development cycle and inspecting the output will lead to great 
enlightenment on the part of the Cython user. Perhaps this should be 
advertised more prominently? I always do this with any Cython-generated 
code, and it works wonders.

> My proposal: Introduce an explicit "buffer syntax":
> arr = np.zeros(..)
> cdef int[:,:] buf = arr # 2D buffer

My initial reaction is that it seems to be a second implementation of 
buffer interaction Cython, and therefore yet another thing to keep in 
mind and it's unclear to me how different it would be from the 
"traditional" Cython numpy ndarray behavior and how the behavior of the 
two approaches might differ, perhaps in subtle ways. So that's a 
disadvantage from my perspective. I agree that some of your ideas are 
advantages, however. Also, it seems it would allow one to (more easily) 
interact with buffer objects in sophisticated ways without needing the 
GIL, which is another advantage.

Could some or all of this be added to the current numpy buffer 
implementation, or does it really need the new syntax?

Also, is there anything possible with buffer objects that would be 
limited by the choice of syntax you propose? I imagine this might not 
work with structured data types (then again, it might...).

More information about the Numpy-discussion mailing list