On 10/31/2012 02:20 PM, Ian Kelly wrote:
On Wed, Oct 31, 2012 at 7:42 AM, Andrew Robinson wrote:
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.
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....
eg: Lists would be forbidden....
Since functions, and subclasses, can be test evaluated by int(
the_thing_to_try ) and *[] can too,
generality need not be lost for generating nothing or numbers.
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.
I missed something... (but then that's why we're still talking about it...)
Reading the PEP, it notes that *only* integers (or longs) are permitted
in slice syntax.
(Overlooking None, of course... which is strange...)
The PEP gives the only exceptions as objects with method "__index__".
Automatically, then, an empty list is forbidden (in slice syntax).
However, What you did, was circumvent the PEP by passing an empty list
directly to slice(), and avoiding running it through slice syntax
processing.
So...
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.)
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.
Hmmm.....
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.
Ethan Fullman mentioned that he used the names of fields, "instead of
having to remember the _offsets_"; Which means that his values _do
convert_ to offset numbers
His example was actually given in slice syntax notation [::].
Hence, his objects must have an index() method, correct?.
Therefore, I still see no reason why it is permissible to assign
non-numerical (non None) items
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.
A side note:
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!
So, what's the psychology behind allowing slice() to hold objects which
are not converted to ints/longs in the first place?
--
http://mail.python.org/mailman/listinfo/python-list
