Status of PEP's?

[Greg Ewing]

Raymond Hettinger wrote:
> 
> Even for symmetric tables, a default direction should be assigned
> (say, row-major).  Then, the normal pythonic approach to nested
> lists or tuples can be used.

But part of the beauty of it is that it allows you
to treat symmetric tables symmetrically, rather than
have to know about and remember the "default direction".
E.g. to iterate in the opposite order from usual:

  for j in indices(myarray, 1):
    for i in indices(myarray, 0):
      do_something_with(myarray[i, j])

This fits in nicely with Numeric arrays, which can
be sliced and diced very flexibly without any
directional bias at all.

> forget the new
> notation, save the repeated calls to len(), and use just one sample len()
> from each dimension
> 
> rowcnt, colcnt = len(arr), len(arr[0])

You mean like:

  row_indices = indices(myarray, 0)
  col_indices = indices(myarray, 1)
  for i in row_indices:
    for j in col_indices:
      ...

> Given a ragged right, what would looping
> over columns do with:
>   10  20  30
>   40  50  60  70 80
>   90  11  12  13

Outside the scope of my proposal. This is not a 
2-dimensional table, it is a 1-dimensional table
of 1-dimensional tables. Calling indices(..., 1)
on it would raise an exception, just as doing
the same to a list would.

> Let's use the optional argument for something different:
>     indices( anIterable, [start, [stop]] )
> Now, you can make friends with people who number their
> arrays starting at one instead of zero ;)

sub_indices = indices(anIterable)[start:stop]

Now you're friends with them without even
having to *know* where their indices start
(or even whether they're contiguous or not!)

> Also, indices() and indexed() should return a generator instead
> of a fully evaluated list.  Why eat-up memory unnecessarily.

Certainly. (Actually, I would make it a lazy sequence
a la xrange, so that my second example above would work
(i.e. it needs to be re-usable)).

> One final note, if indexed() is available, why would indices()
> ever be needed?

* It doesn't generalise well to symmetric multi-dimensional
use.

* Iterating over parallel lists can be written more
symmetrically with it:

  for i in indices(list1):
    do_something_with(list1[i], list2[i])

looks better to me than

  for i, item1 in indexed(list1):
    do_something_with(item, list2[i])

* Also, I just don't like indexed() for some reason. It
seems to be doing too much at once. I wouldn't object
to its existence, but I wouldn't like to have to use
it all the time.

-- 
Greg Ewing, Computer Science Dept, University of Canterbury,	  
Christchurch, New Zealand
To get my email address, please visit my web page:	  
http://www.cosc.canterbury.ac.nz/~greg