Negative array indicies and slice()
Andrew Robinson
andrew3 at r3dsolutions.com
Tue Oct 30 18:25:54 EDT 2012
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>
More information about the Python-list
mailing list