(Hmm. I'm really not that against the approach. But I'll make sure the arguments against it are at least heard.)
I see two kinds of uses for arrays in Cython: 1) Users that simply wants to allocate an array and do stuff with it. In these cases, having something a bit more capable than a standard array is always going to be an advantage -- even if one doesn't use anything but C array capabilities, being able to quickly insert a print statement to dump the array during debugging, pass it to NumPy functions for debugging purposes (hmmm, what's wrong...perhaps "any(x > 1)"?) and so on is convenient _during development_. (Though not necesarrily NumPy, see below). 2) One wants to know exactly what is going on and be as near C as possible, possibly when wrapping C libraries. But then, nothing can beat try/finally anyway, which really isn't that bad to write and makes it very clear exactly what is going on: cdef char* data = NULL try: data = getmem(100) ... finally: if data: free(data) # can't remember if free checks for null, but could make xfree anyway. Introducing some special syntax candy for the landscape that is "in-between" these two options just doesn't seem worth it (it makes the Cython language heavier and ultimately more difficult to learn). Especially when with this syntax candy a) it looks like the data is going to be allocated on the stack b) in a language that doesn't already have a concept of allocating objects on the stack (as opposed to C and C++), and c) magically it doesn't allocate it on the stack anyway (BTW, not using try/finally in the SAGE code posted does to me (to be honest) just fall into the category of bad and/or sloppy programming, and one shouldn't make changes to Cython on the basis of that code.) If NumPy is overkill then perhaps one should instead (as has been suggested a few times already the last day) make another "buffer" library that operates in the same manner with respect to Cython (reference counted etc., but no syntax candy) but is simpler (always one-dimensional char* buffer for instance). This could quickly be implemented in an inlineable pxd file that is shipped with Cython, and potentially be inlined completely in a few years of Cython development. BTW: Why would NumPy be overkill? Because of a few extra bytes of memory per array object? Invoking the incantation "overkill" to me only suggests the Not Built Here syndrome, I always like to talk about specific, more rational reasons like memory usage, runtime performance, library dependency, ... Dag Sverre _______________________________________________ Cython-dev mailing list Cython-dev@codespeak.net http://codespeak.net/mailman/listinfo/cython-dev
