Sasha wrote:
On 3/23/06, Travis Oliphant <oliphant@ee.byu.edu> wrote:
At any rate, if the fortran flag is there, we need to specify the contiguous case as well. So, either propose a better interface (we could change it still --- the fortran flag doesn't have that much history) to handle the situation or accept what I do ;-)
Let me try. I propose to eliminate the fortran flag in favor of a more general "strides" argument. This argument can be either a sequence of integers that becomes the strides, or a callable object that takes shape and dtype arguments and return a sequence that becomes the strides. For fortran and c order functions that generate appropriate stride sequences should be predefined to enable array(..., strides=fortran, ...) and array(..., strides=contiguous).
I like the idea of being able to create an array with custom strides. The applications aren't entirely clear yet, but it does seem like it could have some interesting and useful consequences. That said, I don't think this belongs in 'array'. Historically, array has been used for all sorts of array creation activities, which is why it always seems to have a wide, somewhat incoherent interface. However, most uses of array() boil down to one thing: creating a *new* array from a python object. My preference would be to focus on that functionality for array() and spin of it's other historical uses and new uses, like this custom strided array stuff, into separate factory functions. For example (and just for example, I make no great claims for either this name or interface): a = array_from_data(a_buffer_object, dtype, dims, strides) One thing that you do make clear is that contiguous and fortran should really two values of the same flag. If you combine this with one other simplification: array() always copies, we end up with a nice thin interface: # Create a new array in 'order' order. Defaults to "C" order. array(object, dtype=None, order="C"|"FORTRAN") and # Returns an array. If object is an array and order is satisfied, return object otherwise a new array. # If order is set the returned array will be contiguous and have that ordering asarray(object, dtype=None, order=None|"C"|"FORTRAN") # Just the same, but allow subtypes. asanyarray(object, dtype=None, order=None|"C"|"FORTRAN") You could build asarray, asanyarray, etc on top of the proposed array without problems by using type(object)==ndarray and isinstance(type, ndarray) respectively. Stuff like convenience functions for minnd would also be easy to build on top of there. This looks great to me (pre-coffee). Embrace simplicity: you have nothing to lose but your clutter;) Regards, -tim