Thoughts on PEP284

[Stephen Horne]

On Tue, 23 Sep 2003 12:43:34 -0700, Tim Hochberg
<tim.hochberg at ieee.org> wrote:

>I know someone's going to suggest that, since I'm already using slices, 
>I should be in favor of int[a:b:c] or similar. But, that doesn't work 
>any better than range with reversed ranges since you still have to use 
>two slices to make things clear. That is, to get the equivalent of 
>``range(n-1,-1,-1)`` one would need to use ``int[n-1:-1:-1]``, which is 
>no clearer, or ``int[:n][::-1]`` which doesn't seem like a particular 
>win over ``range(n)[::-1]``, which you can do now.

One option is, of course...

  for i in int[:n] :
    j = n - i - 1
    ...

or...

  for i in int[1:n+1] :
    j = n - i
    ...


And I thought half-open ranges were supposed to eliminate all those +1
and -1 things!


I mentioned before that I have recently coded an extension module with
some containers, and had to deal with some slicing issues. One issue
which I haven't resolved yet is whether to add some sliceable
properties for alternate slicing methods (mainly slicing by subscript
on associative containers that are by default sliced by key).

Running with this idea, how about...

  for i in int.backward [:n] :
    ...

where 'backward' means you get the same slice, but iterated in reverse
order. Actually, I'd vote for a 'backward' sliceable property in
strings, lists and tuples too (though the name should probably be
changed). I might even make the property give a more general proxy for
the object that behaves as if the items were reversed (though maybe
not - the number of methods to handle for string in particular would
be a nightmare).


A reverse function (not the existing reverse methods which work
in-place) would of course handle most cases perfectly well. Why can't
we have a built-in library function doing something like...

  def reverse(x) :
    y = x [:]
    y.reverse ()
    return y

Trivial, yes - but probably very useful if you ask me. And I swear it
used to exist, though perhaps only for strings (before some string
stuff got converted to methods).


Anyway, I really don't think this 'backward' property should be part
of the standard int type - I'm rapidly getting more into the idea of
taking Seans prototype from here...

Message-ID: <lWYbb.4739$yD1.697869 at news20.bellglobal.com>

removing the inheritance from int (which is probably redundant) and
making it purely into a library object or recipe. It may be time for
me to properly figure out metatypes ;-)


-- 
Steve Horne

steve at ninereeds dot fsnet dot co dot uk