Negative array indicies and slice()

[Andrew Robinson]

Ian,
> >  Looks like it's already been wontfixed back in 2006:
>
> >  http://bugs.python.org/issue1501180
>
> Absolutely bloody typical, turned down because of an idiot.  Who the hell is
> Tim Peters anyway?
> >  I don't really disagree with him, anyway.  It is a rather obscure bug
> >  -- is it worth increasing the memory footprint of slice objects by 80%
> >  in order to fix it?
:D

In either event, a *bug* does exist (at *least* 20% of the time.)  Tim 
Peters could have opened the *appropriate* bug complaint if he rejected 
the inappropriate one.

The API ought to have either 1) included the garbage collection, or 2) 
raised an exception anytime dangerous/leaky data was supplied to slice().

If it is worth getting rid of the 4 words of extra memory required for 
the GC -- on account of slice() refusing to support data with 
sub-objects; then I'd also point out that a very large percentage of the 
time, tuples also contain data (typically integers or floats,) which do 
not further sub-reference objects.  Hence, it would be worth it there too.

OTOH, if the GC is considered acceptable in non-sub-referenced tuples, 
GC ought to be acceptable in slice() as well.

Inconsistency is the mother of surprises; and code bloat through 
exceptions....

> Note that the slice API also includes the slice.indices method.
>
> They also implement rich comparisons, but this appears to be done by
> copying the data to tuples and comparing the tuples, which is actually
> a bit ironic considering this discussion.
Yes, indeed!
I didn't mention the slice.indicies method -- as it's purpose is 
traditionally to *directly* feed the parameters of xrange or range.  ( I 
thought that might start a WAR! ). :D

http://docs.python.org/release/2.3.5/whatsnew/section-slices.html

class FakeSeq:
     ...
	 return FakeSeq([self.calc_item(i) for i in_range(*indices)_])
         else:
             return self.calc_item(i)


And here I'm wondering why we can't just pass range into it directly... :(
------------------------------------

I came across some unexpected behavior in Python 3.2 when experimenting 
with ranges and replacement....

Consider, xrange is missing, BUT:
 >>> a=range(1,5,2)
 >>> a[1]
3
 >>> a[2]
5
 >>> a[1:2]
range(3, 5, 2)

Now, I wondered if it would still print the array or not; eg: if this 
was a __str__ issue vs. __repr__.

 >>> print( a[1:2] ) # Boy, I have to get used to the print's parenthesis
range(3, 5, 2)

So, the answer is *NOPE*.
I guess I need to read the doc's all over again... it's ... well, quite 
different.
--Andrew.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20121030/89828731/attachment.html>