On Wed, Apr 30, 2008 at 3:09 PM, Gael Varoquaux <[EMAIL PROTECTED]> 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.
Gaël, 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. Regards, Alex _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
