[Numpy-discussion] very simple iteration question.

Alexander Michael lxander.m@gmail....
Thu May 1 14:33:54 CDT 2008

On Wed, Apr 30, 2008 at 3:09 PM, Gael Varoquaux
<gael.varoquaux@normalesup.org> wrote:
> On Wed, Apr 30, 2008 at 11:57:44AM -0700, Christopher Barker wrote:
>  > I think I still like the idea of an iterator (or maybe making rollaxis a
>  > method?), but this works pretty well.
>  Generally, in object oriented programming, you expect a method like
>  rollaxis to modify an object inplace. At least that would be my
>  expectation.


I'm not sure where you learned this expectation, as I don't think (but
I could be wrong -- so educate me!) it is universal for OOP nor
encouraged for Python in particular. OOP promotes encapsulation by
providing mechanisms for objects to publish an interface and thereby
hide the details of their inner workings, but I don't think there is a
common OOP philosophy that disallows methods returning views and
requires all transformations be performed in-place. A design
philosophy like you've espoused is tractable in languages that support
overloading, like C++, but it is not tractable in Python (at least not
cleanly within the design of the base language). How do you create a
function that returns a "flat" iterator of a container generically? In
C++, each container would overload the flat function. In Python, your
only hope is to ensure that the flat function only requires a
standardized interface to a container object, but that would likely
depend on the standardized interface including some low level
iteration method from which to build more complex iterators. Even in
C++ where such a design philosophy is possible at some level, objects
often expose const iterators of various sorts as methods. Finally,
Python has plenty of counter-examples to the maxim: all the string
methods because strings are designed to be immutable, set object
methods (even for mutable sets), various iterators for dicts, etc.

On this topic. I would love to see numpy evolve a moderately generic
array interface so that we could write stand-alone functions that work
generically with ndarrays, as well as "masked arrays" and "sparse
arrays" so that there was "one dot-product to rule them all", so to
speak. Right now, you can't use functions like numpy.dot on a
numpy.ma.MaskedArray, for example.


More information about the Numpy-discussion mailing list