Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder1.news.weretis.net!feeder.erje.net!eu.feeder.erje.net!newsfeed.xs4all.nl!newsfeed6.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
Date: Thu, 01 Nov 2012 07:12:15 -0700
From: Ethan Furman <ethan@stoneleaf.us>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: python-list@python.org
Subject: Re: Negative array indicies and slice()
References: <509053F2.6020900@r3dsolutions.com>	<CALwzidnQ2bUdMp8c0xNomabcLHZBBtr_DYSSzvhz3jqeYNkWkQ@mail.gmail.com>	<50912ADC.2020401@r3dsolutions.com>	<CALwzid=_1TCQC5JryemVfVpBLWq=qZwy4hRjCPA5ha0vSm3=VA@mail.gmail.com> <50918716.3080305@r3dsolutions.com>
In-Reply-To: <50918716.3080305@r3dsolutions.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.3149.1351779671.27098.python-list@python.org>
Lines: 83
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:32559

Andrew Robinson wrote:
>   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.

Keep in mind that PEPs represent Python /at that time/ -- as Python
moves forward, PEPs are not updated (this has gotten me a couple times).


>> 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

Furman, actually.  :)

And my values do *not* convert to indices (at least, not automatically).
My __getitem__ code looks like:

     elif isinstance(item, slice):
         sequence = []
         if isinstance(item.start, (str, unicode)) \
         or isinstance(item.stop, (str, unicode)):
             field_names = dbf.field_names(self)
             start, stop, step = item.start, item.stop, item.step
             if start not in field_names or stop not in field_names:
                 raise MissingFieldError(
                     "Either %r or %r (or both) are not valid field names"
                     % (start, stop))
             if step is not None and not isinstance(step, (int, long)):
                 raise DbfError(
                     "step value must be an int or long, not %r"
                     % type(step))
             start = field_names.index(start)
             stop = field_names.index(stop) + 1
             item = slice(start, stop, step)
         for index in self._meta.fields[item]:
             sequence.append(self[index])
         return sequence

In other words, the slice contains the strings, and my code calculates
the offsets -- Python doesn't do it for me.


> His example was actually given in slice syntax notation [::].
> Hence, his objects must have an index() method, correct?.

Nope.

~Ethan~