Great; thanks for the response! This is my first time posting here so it's
good to check back and see an involved discussion on the question I had--
namely, how to extract the buffer of a numpy array in Cython.

After reading through all the responses, it appears as though Sturla's
solution:

<dtype_t*>  np.PyArray_DATA(arr)  

is the right way to go. It is superior to the &a[0] solution because it
doesn't require bounds checking, and it is superior to the .data solution
because 1) it won't break as numpy changes and 2) BONUS: it works even on
arrays that haven't been statically casted to a Cython np.ndarray[...]. To
fully understand what I mean by (2), take a look at the following example:

    a = np.arange(10, dtype=int)

    # This works even if a hasn't been casted yet.
    fprintf(stderr, "%lu %lu\n", <size_t>np.PyArray_DATA(a))

    # These cause errors if the array is not casted because a[0] and a.data
return
    # python objects:
    #    cdef size_t broken_ptr1 = &a[0]
    #    cdef size_t broken_ptr2 = a.data

    cdef np.ndarray[long, ndim=1, mode="c"] x = a

    # After casting, everything works and is consistent.
    cdef size_t buf_ptr1 = <size_t> np.PyArray_DATA(x)
    cdef size_t buf_ptr2 = <size_t> &x[0]
    cdef size_t buf_ptr3 = <size_t> x.data

    fprintf(stderr, "%lu %lu %lu\n", buf_ptr1, buf_ptr2, buf_ptr3)

    # Output for an example run-- all addresses are the same, which is what
    # we want:
    #
    # 27354544
    # 27354544 27354544 27354544

Not having to cast the array before extracting the buffer is useful if one
knows the size of the elements one is dealing with, but not necessarily the
type. In particular, I think it's useful if one wants to manipulate numpy
arrays of strings, which Cython doesn't support-- though I'm not sure about
this.

So I think Sturla's solution is what we should use in the future. It has
the same semantics as .data, which I think a lot of people really like, and
it won't be compromised if numpy changes.

Anyone have any other reasons why Sturla's solution might not be a good
idea?

Thanks,
Nader