konrad.hinsen@laposte.net wrote:
On Feb 18, 2005, at 16:23, Robert Kern wrote:
I'm sure there are any number of people who use len(x) as a way to test the sequenceness of x. While it might be okay for rank-0 arrays, extending this to builtin ints and floats may not be a good idea. I'm pretty sure this would get rejected.
For arrays, len(x) == x.shape[0], so len(x) should fail for rank-0 arrays anyway. As it does in Numeric.
I'm not averse to len(x) returning 0 when given a rank-0 array. I see it as giving up one consistency (that scalar-like objects don't have lengths) for another (arrays having a common set of operations that one can expect regardless of rank or shape). My objection was to extending that set of operations to other standard objects where they make less sense. Although the len(x) sequenceness-test is a reasonably common idiom, it's not expected to be foolproof against any input. However, the test shouldn't stop working on core objects that are already there. In any case, len(x) is probably one of the less-common operations one would want to perform seamlessly on scalar and rank-n outputs from Numeric functions. x.typecode() and x.shape would probably top my list. Might our PEP efforts be better spent locating and fixing the places in core Python where rank-0 arrays won't be accepted as core ints and floats? List/tuple indexing is one. Extension code that demands an actual int object where it could be looser might already be considered deficient considering the int/long unification. -- 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