Re: [Python-ideas] [Python-Dev] Inclusive Range
On Tue, Oct 12, 2010 at 01:50:47PM -0400, Terry Reedy wrote: > >That seems to be an undocumented feature. I didn't know it was possible > >to use extra parameters after key in __getitem__. > > They never get passed, and as I said above, should not have been > there in the version I posted. Sorry for the noise. The actual point > is that keys can be tuples and tuples can contain a slice and other > info. All right, I understand where your going with this. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: [Python-ideas] [Python-Dev] Inclusive Range
On 10/12/2010 9:52 AM, Antoon Pardon wrote: On Fri, Oct 08, 2010 at 05:05:26PM -0400, Terry Reedy wrote: But you really seem to be saying is "What if I sometimes want the end points included and sometimes do not?" Slice syntax by itself cannot handle all four cases, only one, one was chosen and that was closed-open. If you want flexibility, consider the following: class my_list(list): def __getitem__(self, key, include_start=True, include_stop=False): Sorry, the above is a holdover from a previous, experimental version. In this version, the extra parameters should be eliminated. This should be just the expected def __getitem__(self, key): if (isinstance(key,tuple) and len(key)==2 and isinstance(key[0], slice) and isinstance(key[1],tuple) and len(key[1])==2): key, (include_start, include_stop) = key Here I unconditionally set the two include variables from the key. The default values are ignored and are pure holdover noise. start,stop,stride = key.indices(len(self)) if include_start == False: start += 1 if include_stop == True: stop += 1 key = slice(start,stop,stride) print(key) return list.__getitem__(self, key) ll = my_list(range(10)) That seems to be an undocumented feature. I didn't know it was possible to use extra parameters after key in __getitem__. They never get passed, and as I said above, should not have been there in the version I posted. Sorry for the noise. The actual point is that keys can be tuples and tuples can contain a slice and other info. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: [Python-ideas] [Python-Dev] Inclusive Range
On Fri, Oct 08, 2010 at 05:05:26PM -0400, Terry Reedy wrote: > But you really seem to be saying is "What if I sometimes want the > end points included and sometimes do not?" Slice syntax by itself > cannot handle all four cases, only one, one was chosen and that was > closed-open. > > If you want flexibility, consider the following: > > class my_list(list): > def __getitem__(self, key, include_start=True, include_stop=False): > if (isinstance(key,tuple) and len(key)==2 and > isinstance(key[0], slice) > and isinstance(key[1],tuple) and len(key[1])==2): > key, (include_start, include_stop) = key > start,stop,stride = key.indices(len(self)) > if include_start == False: > start += 1 > if include_stop == True: > stop += 1 > key = slice(start,stop,stride) > print(key) > return list.__getitem__(self, key) > > ll = my_list(range(10)) That seems to be an undocumented feature. I didn't know it was possible to use extra parameters after key in __getitem__. It also doesn't seem mentioned in the documentation: http://docs.python.org/reference/datamodel.html Object.__getitem__(self, key) Called to implement evaluation of self[key]. For sequence types, the accepted keys should be integers and slice objects. Note that the special interpretation of negative indexes (if the class wishes to emulate a sequence type) is up to the __getitem__() method. If key is of an inappropriate type, TypeError may be raised; if of a value outside the set of indexes for the sequence (after any special interpretation of negative values), IndexError should be raised. For mapping types, if key is missing (not in the container), KeyError should be raised. I'm a bit reluctant to rely on such an undocumented feature. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: [Python-ideas] [Python-Dev] Inclusive Range
Steven D'Aprano writes: > On Fri, 08 Oct 2010 22:10:35 +0200, Hallvard B Furuseth wrote: >> Jed Smith writes: >> a = [1, 2, 3, 4, 5, 6] >> a[::-1] >>> [6, 5, 4, 3, 2, 1] >> >> Nice. Is there a trick to get a "-0" index too? Other than doing 'i or >> len(L)' instead of 'i', that is. > > What exactly are you expecting? I don't understand why you think that > L[-0] and L[0] would be different, when -0 == 0. I don't think that, and I expected just what happened. As Arnaud Delobelle had answered: I can use 'i or None'. -- Hallvard -- http://mail.python.org/mailman/listinfo/python-list
Re: [Python-ideas] [Python-Dev] Inclusive Range
On Mon, Oct 11, 2010 at 05:35:21AM -0700, Ethan Furman wrote: > Antoon Pardon wrote: > >On Sat, Oct 09, 2010 at 01:37:03AM +, Steven D'Aprano wrote: > > > >>On Fri, 08 Oct 2010 15:53:17 -0400, Jed Smith wrote: > >> > > > >I stand by that claim. I think it was fairly obvious that what I meant > >was that it was impossible to give such a numeric value that would work > >with arbitrary L. > > > >if L2 == list(reversed(L1)) and a and b are in the range 1 < x <= len(L), > >we have the following invariant. > > > > L1[a:b] == L2[b-1:a-1:-1] > > Are you sure? I'm sorry, I was not careful enough in writing this down. It should be that the invariant holds for 1 <= x < len >>> a=3 >>> b=7 >>> L1=['e', 'g', 'h', 'k', 'o', 'p', 'r', 't', 'x', 'z'] >>> L2 = list(reversed(L1)) >>> L1 ['e', 'g', 'h', 'k', 'o', 'p', 'r', 't', 'x', 'z'] >>> L2 ['z', 'x', 't', 'r', 'p', 'o', 'k', 'h', 'g', 'e'] >>> L1[a:b] ['k', 'o', 'p', 'r'] >>> L2[b-1:a-1:-1] ['k', 'o', 'p', 'r'] > >However this no longer works if either nr is 0. > > In which case it's not an invariant, is it? The point being that the breaking of the invariant at that point is IMO a sign of bad design. It makes it difficult to use the reversed slice in a general way. More specifically, if you have a function that produces an a1 and b1, that in combination with a list, always gives you the desired slice by writing L[a1:b1]. There is no straigtforward way to transform this a1 and b1 into a2 and b2, so that L[a2:b2:-1] is the reversed of L[a1:b1] -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: [Python-ideas] [Python-Dev] Inclusive Range
Antoon Pardon wrote: On Sat, Oct 09, 2010 at 01:37:03AM +, Steven D'Aprano wrote: On Fri, 08 Oct 2010 15:53:17 -0400, Jed Smith wrote: On Fri, Oct 8, 2010 at 1:26 PM, Steven D'Aprano wrote: On Fri, 08 Oct 2010 10:21:16 +0200, Antoon Pardon wrote: Personnaly I find it horrible that in the following expression: L[a:b:-1], it is impossible to give a numeric value to b, that will include L[0] into the reversed slice. L = [1, 2, 3, 4, 5] L[5:-6:-1] [5, 4, 3, 2, 1] a = [1, 2, 3, 4, 5, 6] a[::-1] [6, 5, 4, 3, 2, 1] Well of course that works, that is the standard Python idiom for reversing a sequence. But the point was that Antoon claimed that there is no numeric value for the end position that will include L[0] in the reversed slice. My example shows that this is not correct. I stand by that claim. I think it was fairly obvious that what I meant was that it was impossible to give such a numeric value that would work with arbitrary L. if L2 == list(reversed(L1)) and a and b are in the range 1 < x <= len(L), we have the following invariant. L1[a:b] == L2[b-1:a-1:-1] Are you sure? Python 2.5.4 (r254:67916, Dec 23 2008, 15:10:54) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. --> L1 = [1, 2, 3, 4, 5] --> L2 = list(reversed(L1)) --> L1 [1, 2, 3, 4, 5] --> L2 [5, 4, 3, 2, 1] --> L1[2:5:1], L2[4:1:-1] ([3, 4, 5], [1, 2, 3]) However this no longer works if either nr is 0. In which case it's not an invariant, is it? ~Ethan~ -- http://mail.python.org/mailman/listinfo/python-list
Re: [Python-ideas] [Python-Dev] Inclusive Range
On Mon, Oct 11, 2010 at 06:25:49AM -0400, Dave Angel wrote: > On 2:59 PM, Antoon Pardon wrote: > >On Sat, Oct 09, 2010 at 01:37:03AM +, Steven D'Aprano wrote: > > > >>But the point was that Antoon claimed that there is no numeric value for > >>the end position that will include L[0] in the reversed slice. My example > >>shows that this is not correct. > >I stand by that claim. I think it was fairly obvious that what I meant > >was that it was impossible to give such a numeric value that would work > >with arbitrary L. > > > >if L2 == list(reversed(L1)) and a and b are in the range 1< x<= len(L), > >we have the following invariant. > > > > L1[a:b] == L2[b-1:a-1:-1] > > > >However this no longer works if either nr is 0. That means that if a and > >be are computed values, that may return 0 to indicate which slice you > >want; that if you want the reversed slice, there is no straightforward > >way to get that reversed slice with extended slice notation. > > > Rather than worrying about how to get from one kind of slice to > another, consider that for both forward and reversed slices, there > are edge conditions that are painful. Why should I not worry. I used to not worry and got stung. I once without a worry, wrote a testunit that naively depended on the above invariant. That these edge conditions are painful for the user of the language is IMO a sign of poor design. > I think the fact that there are two other idioms that handle it > makes the "problem" mostly irrelevant. Either reverse the slice > after taking it, or use a second slice to chop off zero or more > items from the end. No the problem is not mostly irrelevant. Sure it is irrelevant for those who are well informed and know other ways to get what they want. But for those who are not that fortunate, it is nasty surprise waiting to happen. If there are other ways to get what you want and this way can produce some nasty surprises, I would think that the way this was included, was a big mistake. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: [Python-ideas] [Python-Dev] Inclusive Range
On 2:59 PM, Antoon Pardon wrote: On Sat, Oct 09, 2010 at 01:37:03AM +, Steven D'Aprano wrote: But the point was that Antoon claimed that there is no numeric value for the end position that will include L[0] in the reversed slice. My example shows that this is not correct. I stand by that claim. I think it was fairly obvious that what I meant was that it was impossible to give such a numeric value that would work with arbitrary L. if L2 == list(reversed(L1)) and a and b are in the range 1< x<= len(L), we have the following invariant. L1[a:b] == L2[b-1:a-1:-1] However this no longer works if either nr is 0. That means that if a and be are computed values, that may return 0 to indicate which slice you want; that if you want the reversed slice, there is no straightforward way to get that reversed slice with extended slice notation. Rather than worrying about how to get from one kind of slice to another, consider that for both forward and reversed slices, there are edge conditions that are painful. For forward slices, that's when you sometimes want the end of the list, and sometimes don't. The expression that says how close to the end you want can be -1, -2, etc. But there's no -0 notation to say "up and including the last element". For that, you just omit the ending point, or use the length. Similarly for reverse slice that may end at the beginning. In order to generalize it, you have to include the length in your expression. I think the fact that there are two other idioms that handle it makes the "problem" mostly irrelevant. Either reverse the slice after taking it, or use a second slice to chop off zero or more items from the end. DaveA -- http://mail.python.org/mailman/listinfo/python-list
Re: [Python-ideas] [Python-Dev] Inclusive Range
On Sat, Oct 09, 2010 at 01:37:03AM +, Steven D'Aprano wrote: > On Fri, 08 Oct 2010 15:53:17 -0400, Jed Smith wrote: > > > On Fri, Oct 8, 2010 at 1:26 PM, Steven D'Aprano > > wrote: > >> On Fri, 08 Oct 2010 10:21:16 +0200, Antoon Pardon wrote: > >> > >>> Personnaly I find it horrible > >>> that in the following expression: L[a:b:-1], it is impossible to give > >>> a numeric value to b, that will include L[0] into the reversed slice. > >> > >> > >> > > L = [1, 2, 3, 4, 5] > > L[5:-6:-1] > >> [5, 4, 3, 2, 1] > > > a = [1, 2, 3, 4, 5, 6] > a[::-1] > > [6, 5, 4, 3, 2, 1] > > > Well of course that works, that is the standard Python idiom for > reversing a sequence. > > But the point was that Antoon claimed that there is no numeric value for > the end position that will include L[0] in the reversed slice. My example > shows that this is not correct. I stand by that claim. I think it was fairly obvious that what I meant was that it was impossible to give such a numeric value that would work with arbitrary L. if L2 == list(reversed(L1)) and a and b are in the range 1 < x <= len(L), we have the following invariant. L1[a:b] == L2[b-1:a-1:-1] However this no longer works if either nr is 0. That means that if a and be are computed values, that may return 0 to indicate which slice you want; that if you want the reversed slice, there is no straightforward way to get that reversed slice with extended slice notation. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: [Python-ideas] [Python-Dev] Inclusive Range
On Fri, 08 Oct 2010 22:10:35 +0200, Hallvard B Furuseth wrote:
> Jed Smith writes:
> a = [1, 2, 3, 4, 5, 6]
> a[::-1]
>> [6, 5, 4, 3, 2, 1]
>
> Nice. Is there a trick to get a "-0" index too? Other than doing 'i or
> len(L)' instead of 'i', that is.
What exactly are you expecting? I don't understand why you think that
L[-0] and L[0] would be different, when -0 == 0. I'm also unsure why you
think that there's anything more ("too") to get -- the example shown
reverses the entire list.
Perhaps if you show what result you are expecting, we can show what slice
to give to get it.
L = [1,2,3,4,5]
L[2:-2], L[2:-1], L[2:-0] # not quite right:-)
> ([3], [3, 4], [])
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: [Python-ideas] [Python-Dev] Inclusive Range
On Fri, 08 Oct 2010 15:53:17 -0400, Jed Smith wrote: > On Fri, Oct 8, 2010 at 1:26 PM, Steven D'Aprano > wrote: >> On Fri, 08 Oct 2010 10:21:16 +0200, Antoon Pardon wrote: >> >>> Personnaly I find it horrible >>> that in the following expression: L[a:b:-1], it is impossible to give >>> a numeric value to b, that will include L[0] into the reversed slice. >> >> >> > L = [1, 2, 3, 4, 5] > L[5:-6:-1] >> [5, 4, 3, 2, 1] > a = [1, 2, 3, 4, 5, 6] a[::-1] > [6, 5, 4, 3, 2, 1] Well of course that works, that is the standard Python idiom for reversing a sequence. But the point was that Antoon claimed that there is no numeric value for the end position that will include L[0] in the reversed slice. My example shows that this is not correct. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: [Python-ideas] [Python-Dev] Inclusive Range
On 10/8/2010 4:21 AM, Antoon Pardon wrote:
On Wed, Oct 06, 2010 at 05:28:13PM -0400, Terry Reedy wrote:
Strings and tuples are not natural numbers, but do have least
members ('' and ()), so the bottom end had better be closed.
Why?
Because otherwise one can never include the least member in a slice.
> The fact that we have a bottom element in the item space,
doesn't imply that the sequence I need is easiest defined by
using an inclusive lower limit. What if I wanted all none-empty
strings/tuples keys in the tree?
Use 'a' as the lower bound, it being the string that follows ''.
But you really seem to be saying is "What if I sometimes want the end
points included and sometimes do not?" Slice syntax by itself cannot
handle all four cases, only one, one was chosen and that was closed-open.
If you want flexibility, consider the following:
class my_list(list):
def __getitem__(self, key, include_start=True, include_stop=False):
if (isinstance(key,tuple) and len(key)==2 and
isinstance(key[0], slice)
and isinstance(key[1],tuple) and len(key[1])==2):
key, (include_start, include_stop) = key
start,stop,stride = key.indices(len(self))
if include_start == False:
start += 1
if include_stop == True:
stop += 1
key = slice(start,stop,stride)
print(key)
return list.__getitem__(self, key)
ll = my_list(range(10))
print('standard:', ll[2], ll[1:3], ll[1:3,(True,False)])
print('delete start:', ll[1:3,(False,False)])
print('shift:', ll[1:3,(False,True)])
print('extend stop:', ll[1:3,(True,True)])
>>>
slice(1, 3, 1)
standard: 2 [1, 2] [1, 2]
slice(2, 3, 1)
delete start: [2]
slice(2, 4, 1)
shift: [2, 3]
slice(1, 4, 1)
extend stop: [1, 2, 3]
>>>
Modify to taste ;-)
--
Terry Jan Reedy
--
http://mail.python.org/mailman/listinfo/python-list
Re: [Python-ideas] [Python-Dev] Inclusive Range
Hallvard B Furuseth writes: > Jed Smith writes: > a = [1, 2, 3, 4, 5, 6] > a[::-1] >> [6, 5, 4, 3, 2, 1] > > Nice. Is there a trick to get a "-0" index too? > Other than doing 'i or len(L)' instead of 'i', that is. > L = [1,2,3,4,5] L[2:-2], L[2:-1], L[2:-0] # not quite right:-) > ([3], [3, 4], []) 'i or None' -- Arnaud -- http://mail.python.org/mailman/listinfo/python-list
Re: [Python-ideas] [Python-Dev] Inclusive Range
Jed Smith writes: > On Fri, Oct 8, 2010 at 1:26 PM, Steven D'Aprano > wrote: >> On Fri, 08 Oct 2010 10:21:16 +0200, Antoon Pardon wrote: >> >>> Personnaly I find it horrible >>> that in the following expression: L[a:b:-1], it is impossible to give a >>> numeric value to b, that will include L[0] into the reversed slice. ^^ >> >> >> > L = [1, 2, 3, 4, 5] > L[5:-6:-1] >> [5, 4, 3, 2, 1] > a = [1, 2, 3, 4, 5, 6] a[::-1] > [6, 5, 4, 3, 2, 1] b doesn't have a numeric value though. -- Arnaud -- http://mail.python.org/mailman/listinfo/python-list
Re: [Python-ideas] [Python-Dev] Inclusive Range
Jed Smith writes: a = [1, 2, 3, 4, 5, 6] a[::-1] > [6, 5, 4, 3, 2, 1] Nice. Is there a trick to get a "-0" index too? Other than doing 'i or len(L)' instead of 'i', that is. >>> L = [1,2,3,4,5] >>> L[2:-2], L[2:-1], L[2:-0] # not quite right:-) ([3], [3, 4], []) -- Hallvard -- http://mail.python.org/mailman/listinfo/python-list
Re: [Python-ideas] [Python-Dev] Inclusive Range
On Fri, Oct 8, 2010 at 1:26 PM, Steven D'Aprano wrote: > On Fri, 08 Oct 2010 10:21:16 +0200, Antoon Pardon wrote: > >> Personnaly I find it horrible >> that in the following expression: L[a:b:-1], it is impossible to give a >> numeric value to b, that will include L[0] into the reversed slice. > > > L = [1, 2, 3, 4, 5] L[5:-6:-1] > [5, 4, 3, 2, 1] >>> a = [1, 2, 3, 4, 5, 6] >>> a[::-1] [6, 5, 4, 3, 2, 1] -- Jed Smith j...@jedsmith.org -- http://mail.python.org/mailman/listinfo/python-list
Re: [Python-ideas] [Python-Dev] Inclusive Range
On Fri, 08 Oct 2010 10:21:16 +0200, Antoon Pardon wrote: > Personnaly I find it horrible > that in the following expression: L[a:b:-1], it is impossible to give a > numeric value to b, that will include L[0] into the reversed slice. >>> L = [1, 2, 3, 4, 5] >>> L[5:-6:-1] [5, 4, 3, 2, 1] -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: [Python-ideas] [Python-Dev] Inclusive Range
On Wed, Oct 06, 2010 at 05:28:13PM -0400, Terry Reedy wrote:
> On 10/6/2010 7:14 AM, Antoon Pardon wrote:
>
> >>That right-hand-half-open intervals (i.e. a<= i< b, equivalently [a,
> >>b) ), which are what Python uses, are to be preferred.
> >>(See aforelinked PDF: http://www.cs.utexas.edu/users/EWD/ewd08xx/EWD831.PDF)
>
> This specifically discusses subsequences of 'natural numbers'.
Sure, but I don't think we should limit ourselves to subsequence of
natural numbers. It is my impression that orginally slices were
also limited to indicating subsequences of natural numbers. This
original limitation, has guided its semantics that resulted in
what we have now,
> >The problem is that the slice notation is sometimes handy in situations where
> >an open interval doesn't allow easily to mark what you want.
> >
> >For instance I have at one time implemted a Tree. This is a dict like
> >structure
> >but it allows to visit the keys in order. Because there is an order, slice
> >notation can make sense. e.g. if T is a tree with names as keys,
> >T['bea':'mike']
> >is a subtree where we have for each key that 'bea'<= key< 'mike'.
>
> >But what if I wanted a subtree where 'mike' was still included, but nothing
> >further?
> >Or what if the keys were floats or tuples and I wanted an inclusive upper
> >boundary?
>
> Strings and tuples are not natural numbers, but do have least
> members ('' and ()), so the bottom end had better be closed.
Why? The fact that we have a bottom element in the item space,
doesn't imply that the sequence I need is easiest defined by
using an inclusive lower limit. What if I wanted all none-empty
strings/tuples keys in the tree? The easiest way to specify that
would be by saying the key needed to be larger than the empty
string/tuple. If the keys were strings I could fudge it by starting
with chr(0), but what value should use as start, if I wanted all
non-empty tuples?
> Since
> substracting strings and tuples in meaningless, the argument of
> having stop-start == number of items does not apply. Floats can be
> subtracted, but the result in not a count of included items. So
> write the .__getitem__ method of *your* class how it best fits your
> use-cases.
My use cases depend on the specific problem I need to solve. Sometimes
the problem is easiest solved with an inclusive limit, sometimes it
is with an exclusive limit. The slice notation although at first sight
a natural way to specify the boundaries, seems on closer inspection
to be too limited.
> Just be aware that an inclusive upper boundary means that
> s[a:b]+s[b:c] will no longer be s[a:c] because b will be duplicated.
> Let me also point out integer slices for builtins are adjusted to
> that they refer to actual slice positions. This is harder to do with
> strings;-). Also, suppose you want all strings beginning with 'a' or
> 'b'. With an open upper end, Tree['a':'c'] will do that. With closed
> upper end, you would need
> Tree['a':'bbb'] or somesuch.
Yes I know. I'm starting to think about aproaching this in a different
manner.
> >And what if you needed the reverse sequence. If you start with inclusive
> >limit,
> >the reverse of a<= item<= b is b>= item>= a. If the second limit is to be
> >exclusive the reverse of a<= item< b becomes (b - 1)>= item> (a - 1).
>
> Slices with positive strides can be defined and understood in terms
> of slice positions before the first item, between all successive
> pairs of items and after the last. By this same definition and
> understanding, s[b:a:-1] should be reversed(s[a:b]), which is what
> many expect. It is not because the definition is given in terms of
> the translation into indexes and blindly applied to the case of
> negative strides without the needed adjustment. I consider this a
> design mistake, at least for many uses. (Extended slices, if not
> extended slicing, were added for numerical Python and they may have
> wanted the current definition for negative strides.)
I agree that this is a design mistake. Personnaly I find it horrible
that in the following expression: L[a:b:-1], it is impossible to
give a numeric value to b, that will include L[0] into the reversed
slice. It is the reason why I avoid reversed slices as much as
possible.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
Re: [Python-ideas] [Python-Dev] Inclusive Range
On 10/6/2010 7:14 AM, Antoon Pardon wrote:
That right-hand-half-open intervals (i.e. a<= i< b, equivalently [a,
b) ), which are what Python uses, are to be preferred.
(See aforelinked PDF: http://www.cs.utexas.edu/users/EWD/ewd08xx/EWD831.PDF)
This specifically discusses subsequences of 'natural numbers'.
The problem is that the slice notation is sometimes handy in situations where
an open interval doesn't allow easily to mark what you want.
For instance I have at one time implemted a Tree. This is a dict like structure
but it allows to visit the keys in order. Because there is an order, slice
notation can make sense. e.g. if T is a tree with names as keys, T['bea':'mike']
is a subtree where we have for each key that 'bea'<= key< 'mike'.
But what if I wanted a subtree where 'mike' was still included, but nothing
further?
Or what if the keys were floats or tuples and I wanted an inclusive upper
boundary?
Strings and tuples are not natural numbers, but do have least members
('' and ()), so the bottom end had better be closed. Since substracting
strings and tuples in meaningless, the argument of having stop-start ==
number of items does not apply. Floats can be subtracted, but the result
in not a count of included items. So write the .__getitem__ method of
*your* class how it best fits your use-cases.
Just be aware that an inclusive upper boundary means that s[a:b]+s[b:c]
will no longer be s[a:c] because b will be duplicated. Let me also point
out integer slices for builtins are adjusted to that they refer to
actual slice positions. This is harder to do with strings;-). Also,
suppose you want all strings beginning with 'a' or 'b'. With an open
upper end, Tree['a':'c'] will do that. With closed upper end, you would
need Tree['a':'bbb'] or somesuch.
And what if you needed the reverse sequence. If you start with inclusive limit,
the reverse of a<= item<= b is b>= item>= a. If the second limit is to be
exclusive the reverse of a<= item< b becomes (b - 1)>= item> (a - 1).
Slices with positive strides can be defined and understood in terms of
slice positions before the first item, between all successive pairs of
items and after the last. By this same definition and understanding,
s[b:a:-1] should be reversed(s[a:b]), which is what many expect. It is
not because the definition is given in terms of the translation into
indexes and blindly applied to the case of negative strides without the
needed adjustment. I consider this a design mistake, at least for many
uses. (Extended slices, if not extended slicing, were added for
numerical Python and they may have wanted the current definition for
negative strides.)
--
Terry Jan Reedy
--
http://mail.python.org/mailman/listinfo/python-list
Re: [Python-ideas] [Python-Dev] Inclusive Range
In message , Antoon Pardon wrote: > Or what if the keys were floats or tuples and I wanted an > inclusive upper boundary? If you’re expecting computer floats to behave as mathematically exact quantities, you’re asking for trouble. -- http://mail.python.org/mailman/listinfo/python-list
Re: [Python-ideas] [Python-Dev] Inclusive Range
On Tue, Oct 05, 2010 at 01:52:39PM -0700, Chris Rebert wrote: > On Tue, Oct 5, 2010 at 1:31 PM, Wolfgang Rohdewald > wrote: > > On Dienstag 05 Oktober 2010, MRAB wrote: > >> > About notation, even if loved right-hand-half-open > >> > intervals, I would wonder about [a,b] noting it. I guess > >> > 99.9% of programmers and novices (even purely amateur) have > >> > learnt about intervals at school in math courses. Both > >> > notations I know of use [a,b] for closed intervals, while > >> > half-open ones are noted either [a,b[ or [a,b). Thus, for > >> > me, the present C/python/etc notation is at best > >> > misleading. So, what about a hypothetical language using > >> > directly math unambiguous notation, thus also letting > >> > programmers chose their preferred semantics (without > >> > fooling others)? End of war? > >> > >> Dijkstra came to his conclusion after seeing the results of > >> students using the programming language Mesa, which does > >> support all 4 forms of interval. > > > > what was his conclusion? > > That right-hand-half-open intervals (i.e. a <= i < b, equivalently [a, > b) ), which are what Python uses, are to be preferred. > (See aforelinked PDF: http://www.cs.utexas.edu/users/EWD/ewd08xx/EWD831.PDF) The problem is that the slice notation is sometimes handy in situations where an open interval doesn't allow easily to mark what you want. For instance I have at one time implemted a Tree. This is a dict like structure but it allows to visit the keys in order. Because there is an order, slice notation can make sense. e.g. if T is a tree with names as keys, T['bea':'mike'] is a subtree where we have for each key that 'bea' <= key < 'mike'. But what if I wanted a subtree where 'mike' was still included, but nothing further? Or what if the keys were floats or tuples and I wanted an inclusive upper boundary? And what if you needed the reverse sequence. If you start with inclusive limit, the reverse of a <= item <= b is b >= item >= a. If the second limit is to be exclusive the reverse of a <= item < b becomes (b - 1) >= item > (a - 1). So what do you do in python, if you are given a list, a lower inclusive and an upper exclusive limit and you have to return the reverse slice. Better don't use L[b-1:a-1:-1], because that may result in a nasty surprise, a surprise that could have been avoided by allowing the second limit to be inclusive. So I don't think the results in MESA are that relevant when you are working in an environment that is not limited to integers in upgoing sequences. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: [Python-ideas] [Python-Dev] Inclusive Range
On Tue, Oct 5, 2010 at 1:31 PM, Wolfgang Rohdewald wrote: > On Dienstag 05 Oktober 2010, MRAB wrote: >> > About notation, even if loved right-hand-half-open >> > intervals, I would wonder about [a,b] noting it. I guess >> > 99.9% of programmers and novices (even purely amateur) have >> > learnt about intervals at school in math courses. Both >> > notations I know of use [a,b] for closed intervals, while >> > half-open ones are noted either [a,b[ or [a,b). Thus, for >> > me, the present C/python/etc notation is at best >> > misleading. So, what about a hypothetical language using >> > directly math unambiguous notation, thus also letting >> > programmers chose their preferred semantics (without >> > fooling others)? End of war? >> >> Dijkstra came to his conclusion after seeing the results of >> students using the programming language Mesa, which does >> support all 4 forms of interval. > > what was his conclusion? That right-hand-half-open intervals (i.e. a <= i < b, equivalently [a, b) ), which are what Python uses, are to be preferred. (See aforelinked PDF: http://www.cs.utexas.edu/users/EWD/ewd08xx/EWD831.PDF) Cheers, Chris -- http://mail.python.org/mailman/listinfo/python-list
Re: [Python-ideas] [Python-Dev] Inclusive Range
On Dienstag 05 Oktober 2010, MRAB wrote: > > About notation, even if loved right-hand-half-open > > intervals, I would wonder about [a,b] noting it. I guess > > 99.9% of programmers and novices (even purely amateur) have > > learnt about intervals at school in math courses. Both > > notations I know of use [a,b] for closed intervals, while > > half-open ones are noted either [a,b[ or [a,b). Thus, for > > me, the present C/python/etc notation is at best > > misleading. So, what about a hypothetical language using > > directly math unambiguous notation, thus also letting > > programmers chose their preferred semantics (without > > fooling others)? End of war? > > Dijkstra came to his conclusion after seeing the results of > students using the programming language Mesa, which does > support all 4 forms of interval. what was his conclusion? -- Wolfgang -- http://mail.python.org/mailman/listinfo/python-list
Re: [Python-ideas] [Python-Dev] Inclusive Range
On 05/10/2010 20:23, spir wrote: On Tue, 05 Oct 2010 13:45:56 +0200 Boris Borcic wrote: Nick Coghlan wrote: [...] Being able to say things like "10:00"<= x< '12:00", 10.0<= x< 12.0, "a"<= x< "n" are much clearer than trying to specify their closed range equivalents. makes one wonder about syntax like : for 10<= x< 20 : blah(x) Mh, I suppose with rich comparisons special methods, it's possible to turn chained comparisons into range factories without introducing new syntax. Something more like for x in (10<= step(1)< 20) : blah(x) About notation, even if loved right-hand-half-open intervals, I would wonder about [a,b] noting it. I guess 99.9% of programmers and novices (even purely amateur) have learnt about intervals at school in math courses. Both notations I know of use [a,b] for closed intervals, while half-open ones are noted either [a,b[ or [a,b). Thus, for me, the present C/python/etc notation is at best misleading. So, what about a hypothetical language using directly math *unambiguous* notation, thus also letting programmers chose their preferred semantics (without fooling others)? End of war? Dijkstra came to his conclusion after seeing the results of students using the programming language Mesa, which does support all 4 forms of interval. -- http://mail.python.org/mailman/listinfo/python-list
