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