Tim Hochberg wrote:
Hi Travis,
First off, let me say that I'm encouraged to see some action towards unifying Numeric/Numarray the split has been somewhat dismaying. Thank you for your efforts in this regard.
I'd like to lobby against flatten(), r() and i(). To a large extent, these duplicate the functionality of flat, real and imag. And, these three methods are defined to sometimes return copies and sometimes return views. That type of interface is a recipe for errors and should only be used as a last resort.
There is, however, a blisteringly common use case for such an interface: you are using the result directly in an expression such that it is only going to be read and never written to. In that case, you want it to never fail (except in truly pathological cases like being out of memory), and you want it to be as efficient as possible and so never produce a copy where you can produce a view. So, I think we need three interfaces for each of this kind of attribute: 1) Getting a view. If a view cannot be obtained, raise an error. Never copy. 2) Getting a copy. Never return a view. 3) Getting *something* the most efficient way possible. Caller beware. While I lean towards making the syntaxes for the first two The Most Obvious Ways To Do It, I think it may be rather important to keep the syntax of the third convenient and short, particularly since it is that case that usually occurs in the middle of already-complicated expressions. -- Robert Kern rkern@ucsd.edu "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter