<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Ian,<br>
<blockquote type="cite">
<pre wrap="">> Looks like it's already been wontfixed back in 2006:
<a class="moz-txt-link-freetext" href="http://bugs.python.org/issue1501180">> http://bugs.python.org/issue1501180</a>
</pre>
<pre wrap="">Absolutely bloody typical, turned down because of an idiot. Who the hell is
Tim Peters anyway? <span class="moz-smiley-s1" title=":)"></span>
</pre>
<pre wrap="">> 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?</pre>
</blockquote>
:D<br>
<br>
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.<br>
<br>
The API ought to have either 1) included the garbage collection, or
2) raised an exception anytime dangerous/leaky data was supplied to
slice().<br>
<br>
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.<br>
<br>
OTOH, if the GC is considered acceptable in non-sub-referenced
tuples, GC ought to be acceptable in slice() as well.<br>
<br>
Inconsistency is the mother of surprises; and code bloat through
exceptions....<br>
<br>
<blockquote type="cite">
<pre wrap="">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. <span class="moz-smiley-s1" title=":-)"></span></pre>
</blockquote>
Yes, indeed!<br>
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<br>
<br>
<a class="moz-txt-link-freetext" href="http://docs.python.org/release/2.3.5/whatsnew/section-slices.html">http://docs.python.org/release/2.3.5/whatsnew/section-slices.html</a><br>
<br>
<pre>class FakeSeq:
...
return FakeSeq([self.calc_item(i) for i in <u>range(*indices)</u>])
else:
return self.calc_item(i)
</pre>
<br>
And here I'm wondering why we can't just pass range into it
directly... :(<br>
------------------------------------<br>
<br>
I came across some unexpected behavior in Python 3.2 when
experimenting with ranges and replacement....<br>
<br>
Consider, xrange is missing, BUT:<br>
>>> a=range(1,5,2)<br>
>>> a[1]<br>
3<br>
>>> a[2]<br>
5<br>
>>> a[1:2]<br>
range(3, 5, 2)<br>
<br>
Now, I wondered if it would still print the array or not; eg: if
this was a __str__ issue vs. __repr__.<br>
<br>
>>> print( a[1:2] ) # Boy, I have to get used to the
print's parenthesis<br>
range(3, 5, 2)<br>
<br>
So, the answer is *NOPE*.<br>
I guess I need to read the doc's all over again... it's ... well,
quite different.<br>
--Andrew.<br>
<br>
</body>
</html>