<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    On 10/31/2012 02:20 PM, Ian Kelly wrote:
    <blockquote
cite="mid:CALwzid=_1TCQC5JryemVfVpBLWq=qZwy4hRjCPA5ha0vSm3=VA@mail.gmail.com"
      type="cite">
      <div class="gmail_quote">On Wed, Oct 31, 2012 at 7:42 AM, Andrew
        Robinson <span dir="ltr"></span> wrote:<br>
        <blockquote class="gmail_quote" style="margin:0 0 0
          .8ex;border-left:1px #ccc solid;padding-left:1ex">
          Then; I'd note:  The non-goofy purpose of slice is to hold
          three data values;  They are either numbers or None.  These
          *normally* encountered values can't create a memory loop.<br>
          So, FOR AS LONG, as the object representing slice does not
          contain an explicit GC pair; I move that we mandate (yes, in
          the current python implementation, even as a *fix*) that its
          named members may not be assigned any objects other than None
          or numbers....<br>
          <br>
          eg: Lists would be forbidden....<br>
          <br>
          Since functions, and subclasses, can be test evaluated by int(
          the_thing_to_try ) and *[] can too,<br>
          generality need not be lost for generating nothing or numbers.<br>
        </blockquote>
        <div><br>
          PEP 357 requires that anything implementing the __index__
          special method be allowed for slicing sequences (and also that
          __index__ be used for the conversion).  For the most part,
          that includes ints and numpy integer types, but other code
          could be doing esoteric things with it.<br>
        </div>
      </div>
    </blockquote>
    <br>
    I missed something... (but then that's why we're still talking about
    it...)<br>
    <br>
    Reading the PEP, it notes that *only* integers (or longs) are
    permitted in slice syntax.<br>
    (Overlooking None, of course... which is strange...)<br>
    <br>
    The PEP gives the only exceptions as objects with method
    "__index__".<br>
    <br>
    Automatically, then, an empty list is forbidden (in slice syntax).<br>
    However,  What you did, was circumvent the PEP by passing an empty
    list directly to slice(), and avoiding running it through slice
    syntax processing. <br>
    <br>
    So...<br>
    Is there documentation suggesting that a slice object is meant to be
    used to hold anything other than what comes from processing a valid
    slice syntax [::]??. (we know it can be done, but that's a different
    Q.)<br>
    <br>
    <br>
    <blockquote
cite="mid:CALwzid=_1TCQC5JryemVfVpBLWq=qZwy4hRjCPA5ha0vSm3=VA@mail.gmail.com"
      type="cite">
      <div class="gmail_quote">
        <div>The change would be backward-incompatible in any case,
          since there is certainly code out there that uses non-numeric
          slices -- one example has already been given in this thread.<br>
        </div>
      </div>
    </blockquote>
    Hmmm.....<br>
    <br>
    Now, I'm thinking -- The purpose of index(), specifically, is to
    notify when something which is not an integer may be used as an
    index;  You've helpfully noted that index() also *converts* those
    objects into numbers.<br>
    <br>
    Ethan Fullman mentioned that he used the names of fields, "instead
    of having to remember the <u>offsets</u>"; Which means that his
    values <u>do convert</u> to offset numbers<br>
    <br>
    His example was actually given in slice syntax notation [::].<br>
    Hence, his objects must have an index() method, correct?.<br>
    <br>
    Therefore, I still see no reason why it is permissible to assign
    non-numerical (non None) items <br>
    as an element of slice().  Or, let me re-word that more clearly -- I
    see no reason that slice named members when used as originally
    intended would ever need to be assigned a value which is not
    *already* converted to a number by index().  By definition, if it
    can't be coerced, it isn't a number.<br>
    <br>
    A side note:<br>
    At 80% less overhead, and three slots -- slice is rather attractive
    to store RGB values in for a picture!  But, I don't think anyone
    would have a problem saying "No, we won't support that, even if you
    do do it!<br>
    <br>
    So, what's the psychology behind allowing slice() to hold objects
    which are not converted to ints/longs in the first place?<br>
    <br>
  </body>
</html>