On Feb 17, 2005, at 19:52, Travis Oliphant wrote:
I like Francesc's suggestion that .typecode return a code and .type return a Python class. What is the attitude and opinion regarding the use of attributes or methods for this kind of thing? It always seems to me so arbitrary as to what is an attribute or what is a method.
My view of pythonicity is that retrieving a value should be written as attribute access. Methods are more appropriate if there are arguments (no choice then anyway) or side effects. So I'd have .type as an attribute. BTW, as the goal is inclusion into the Python core, why not 1) Use Python type objects for array creation and as the values of the .type attribute. 2) Implement scalar types for those array element types that currently have no Python scalar equivalent (e.g. UInt16). 3) Implement the same set of attributes of methods for scalar types and arrays. Then the distinction between scalars and rank-0 arrays would become a minor implementation detail rather than a topic of heated debate. In different words, I propose that the PEP should include unification of scalars and arrays such that for all practical purposes scalars *are* rank-0 arrays.
One thing has always bothered me though. Why is a double complex type Complex64? and a float complex type Complex32. This seems to break the idea that the number at the end specifies a bit width. Why don't we just call it Complex64 and Complex128? Can we change this?
+1
PowerPC it is Float128. Wouldn't it just be easier to specify LDouble or 'g' then special-case your code?
Definitely.
Sometimes it is useful to select out of an array some elements based on it's linear (flattened) index in the array. MATLAB, for example, will allow you to take a three-dimensional array and index it with a single integer based on it's Fortran-order: x(1,1,1), x(2,1,1), ...
Could you give an example where this would be useful? To me this looks like a feature that MATLAB inherited from Fortran, which had it for efficiency reasons in a time when compilers were not so good at optimizing index expressions. I don't lile the "special case" status of such a construct either. It could lead to unpleasant bugs that would be hard to find by those who are not aware of the special case. I'd say that special cases need special justifications - and I don't see one here.
discontiguous arrays. It could be made to work if X.flat returned some kind of specially-marked array, which would then have to be checked every time indexing occurred for any array. Or, there maybe someway to have X.flat return an
I much prefer that approach, assuming there is a real use for this feature.
Capping indexes was proposed because of what numarray does. I can only think that the benefit would be that you don't have to check for and raise an error in the middle of an indexing loop or pre-scan the indexes. But, I suppose this is unavoidalbe, anyway. Currently Numeric allows specifying indexes that are too high in slices. It just chops them. Python allows this too, for slices. So, I guess I'm just specifying Python behavior. Of course indexing with an integer that is too large or too small will raise errors:
I am all for imitating Python list behaviour in arrays, but we should also watch out for pitfalls. Array index expressions are in general much more complex than list index expressions, so the risk of introducing bugs is also much higher, which might well justify a somewhat incompatible approach.
This may be a bit controversial as it is a bit of a change. But, my experience is that quite a bit of extra code is written to check whether or not a calculation returns a Python-scalar (because these don't have the same methods as arrays). In
The only method I can think of is typecode(). But if more array functionality is migrated to arrays, this might become more serious.
When Python needs a scalar it will generally ask the object if it can turn itself into an int or a float. A notable exception is indexing in a list (where Python needs an integer and won't ask the object to convert if it can). But int(b) always returns a Python integer if the array has only 1 element.
Still, this is a major point in practice. There was a Numeric release at some point in history that always returned rank-0 array objects (I don't remember if by design or by mistake), and it broke lots of my code because I was using array elements as indices. Another compatibility issue is routines in C modules that insist on scalar arguments. As I outlined above, I'd prefer a solution in which the distinction disappears from the Python programmer's point of view, even if scalars and rank-0 arrays remain distinct in the implementation (which is reasonable for performance reasons).
I'd like to know what reasons people can think of for ever returning Python scalars unless explicitly asked for.
Other than the pragmatic ones, consistency: arrays are container structures that store elements of particular types. You should get out what you put in. Konrad. -- --------------------------------------------------------------------- Konrad Hinsen Laboratoire Léon Brillouin, CEA Saclay, 91191 Gif-sur-Yvette Cedex, France Tel.: +33-1 69 08 79 25 Fax: +33-1 69 08 82 61 E-Mail: hinsen@llb.saclay.cea.fr ---------------------------------------------------------------------