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.
--
http://mail.python.org/mailman/listinfo/python-list
