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 at ucsd.edu
"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter