konrad.hinsen@laposte.net wrote:
On 18.02.2005, at 23:45, Travis Oliphant wrote:
While open to the idea for Python 3000, Guido does not seem favorable to the idea for Python 2.X The problem, Guido mentions was that float-like objects can convert to ints by truncation and he doesn't want to allow floats to be used as indexes. He feels it would break too much code.
I can agree with that. Basically the problem is the type hierarchy that is too simple (but many if not most programming language suffer from that problem). Type conversions are all handled in the same way, which doesn't give enough flexibility. But we won't change that of course.
Of course underneath, a is not an array of integers (it is an array of homogeneous c-ints converted from the Python integer and so why should a[0] be a Python integer).
That would basically mean to change the status of arrays from generalized sequence objects to something different. Why not, but then this should be made clear to the programmer, in particular by having a different printed representation for rank-0 arrays and scalars. It also means adding some conversion functions, e.g. for extracting a Python Object from a rank-0 Python Object array.
Still, I am worried about two aspects:
1) The amount of confusion this generates among users. The distinction between scalars and rank-0 arrays has no utility for the programmer, it exists only for implementation and political reasons. I am not looking forward to explaining this in my Python courses for beginners.
(+1) If we consider an array as a sequence of objects of a fixed type, numeric or other, it makes sense that when a single object is returned then an object of that type be returned, coverted if necessary for Int8 etc. Returning a zero rank array is an historical pain. It might make sense if all traditional Python objects were of zero rank I can see no merit in that.
2) Compatibility with existing code. I am not sure I will convert my code to such conventions any time soon, because it requires inspecting every single indexing operation in its particular context to see if the index could be a rank-0 integer array. There is no way to spot those cases by textual analysis. So this change could reduce acceptance to the point where there is no interest in pursuing the project any more.
I thought that the intent of Numeric 3 was to produce the best - a new start, without being overly concerned about compatibility. I was glad to see the proposal to abandon "ravel" ( a hangover from APL?). Words should have a clear generally accepted meaning. For "ravel" dictionary.com offers: 1. To separate the fibers or threads of (cloth, for example); unravel. 2. To clarify by separating the aspects of. 3. To tangle or complicate. Colin W.