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

Reply via email to