Negative array indicies and slice()

[Ian Kelly]

On Tue, Oct 30, 2012 at 4:25 PM, Andrew Robinson
<andrew3 at r3dsolutions.com> wrote:
> 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.

Where are you getting that 20% figure from?  Reference cycles
involving slice objects would be extremely rare, certainly far less
than 20%.

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

How would you propose detecting the latter?  At the time data is
supplied to slice() it cannot refer to the slice, as the slice does
not exist yet.  The cycle has to be created after.

> 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.

I disagree.  The proportion of the time that a tuple contains other
collection objects is *much* greater.  This happens regularly.  OTOH,
if I had to hazard a guess at the frequency with which non-atomic
objects are used in slices, it would be a fraction of a fraction of a
fraction of a percent.

> I came across some unexpected behavior in Python 3.2 when experimenting with
> ranges and replacement....
>
> Consider, xrange is missing, BUT:

More accurately, range is gone, and xrange has been renamed range.

>>>> 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'm not sure why you would expect it to print a list here, without an
explicit conversion.  The result of calling range in Python 3 is a
range object, not a list.