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