Negative array indicies and slice()

[Andrew Robinson]

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?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20121031/32350822/attachment.html>