Re: Possible improvement to slice opperations.

Michael Hudson wrote: > Ron Adam <[EMAIL PROTECTED]> writes: >>With current slicing and a negative step... >> >>[ 1 2 3 4 5 6 7 8 9 ] >> -9 -8 -7 -6 -5 -4 -3 -2 -1 -0 >> >>r[-3:] -> [7, 8, 9]# as expected >>r[-3::-1] -> [7, 6, 5, 4, 3, 2, 1, 0] # surprise >> >

Re: Possible improvement to slice opperations.

Ron Adam <[EMAIL PROTECTED]> writes: > Magnus Lycka wrote: >> Ron Adam wrote: [...] >>> REVERSE ORDER STEPPING >>> -- >>> When negative steps are used, a slice operation >>> does the following. (or the equivalent) >>> >>>1. reverse the list >>>2. cut the reversed seque

Re: Possible improvement to slice opperations.

Bengt Richter wrote: > Then the question is, do we need sugar for reversed(x.[a:b]) > or list(reversed(x.[a:b])) for the right hand side of a statement, > and do we want to to use both kinds of intervals in slice assignment? > (maybe and yes ;-) Yes, I think this is the better way to do it, as th

Re: Possible improvement to slice opperations.

On Tue, 06 Sep 2005 18:34:13 +0200, Magnus Lycka <[EMAIL PROTECTED]> wrote: [...] > >Then you need to view it more in the mathematical way of >half-open (or half-closed if you prefer) intervals. > >[a,b) = { x | a <= x < b } > Funny, I just posted with the same thought (and some additional consider

Re: Possible improvement to slice opperations.

On Tue, 06 Sep 2005 10:31:33 GMT, Ron Adam <[EMAIL PROTECTED]> wrote: >Steve Holden wrote: [...] > >> My point was that you can make those changes in your own code, leaving >> others to accept the situation as it is. > >It's only a suggestion and an interesting idea I thought I would share >and s

Re: Possible improvement to slice opperations.

Magnus Lycka wrote: > Ron Adam wrote: > >> Ok, lets see... This shows the problem with using the gap indexing >> model. >> >> L = range(10) >> >> [ 0 , 1 , 2 , 3 , 4 , 5 , 6 , 7 , 8 , 9 ] # elements >> 0 1 2 3 4 5 6 7 8 9 10 # index's >> >> L[3::1] -> [3, 4, 5, 6, 7, 8

Re: Possible improvement to slice opperations.

Patrick Maupin wrote: > Ron Adam wrote: > > >>>This should never fail with an assertion error. You will note that it >>>shows that, for non-negative start and end values, slicing behavior is >>>_exactly_ like extended range behavior. > > >>Yes, and it passes for negative start and end values a

Re: Possible improvement to slice opperations.

Ron Adam wrote: > Ok, lets see... This shows the problem with using the gap indexing model. > > L = range(10) > > [ 0 , 1 , 2 , 3 , 4 , 5 , 6 , 7 , 8 , 9 ] # elements > 0 1 2 3 4 5 6 7 8 9 10 # index's > > L[3::1] -> [3, 4, 5, 6, 7, 8, 9] 3rd index to end... ok > L[3

Re: Possible improvement to slice opperations.

Ron Adam wrote: >> This should never fail with an assertion error. You will note that it >> shows that, for non-negative start and end values, slicing behavior is >> _exactly_ like extended range behavior. > Yes, and it passes for negative start and end values as well. Umm, no: .>> for stride

Re: Possible improvement to slice opperations.

Steve Holden wrote: > Ron Adam wrote: > >> Steve Holden wrote: >> >> What misconception do you think I have? >> > This was not an ad hominem attack but a commentary on many attempts to > "improve" the language. Ok, No problem. ;-) >> No one has yet explained the reasoning (vs the mechanics)

Re: Possible improvement to slice opperations.

Patrick Maupin wrote: > I previously wrote (in response to a query from Ron Adam): > > >>In any case, you asked for a rationale. I'll give you mine: >> >> >L = range(10) >L[3:len(L):-1] == [L[i] for i in range(3,len(L),-1)] >> >>True >> > > After eating supper, I just realized that I c

Re: Possible improvement to slice opperations.

Terry Reedy wrote: >>Ron Adam wrote: >> >> >>>However, I would like the inverse selection of negative strides to be >>>fixed if possible. If you could explain the current reason why it does >>>not return the reverse order of the selected range. > > > To repeat, the current reason is compatibilit

Re: Possible improvement to slice opperations.

I previously wrote (in response to a query from Ron Adam): > In any case, you asked for a rationale. I'll give you mine: > > >>> L = range(10) > >>> L[3:len(L):-1] == [L[i] for i in range(3,len(L),-1)] > True > >>> After eating supper, I just realized that I could probably make my point a bit c

Re: Possible improvement to slice opperations.

> No one has yet explained the reasoning (vs the mechanics) of the > returned value of the following. > > L = range(10) > L[3::-1] > > So far every attempt to explain it has either quoted the documents which > don't address that particular case, or assumed I'm misunderstanding > something,

Re: Possible improvement to slice opperations.

On Mon, 05 Sep 2005 17:10:05 -0400, Steve Holden <[EMAIL PROTECTED]> wrote: >Paul Rubin wrote: >> Steve Holden <[EMAIL PROTECTED]> writes: >> >>>Given that Python has a 1's-complement operator already I don;t see >>>why you can't just leave Python alone and use it, >> >> >> What's the meaning o

Re: Possible improvement to slice opperations.

On 05 Sep 2005 12:58:00 -0700, Paul Rubin wrote: >Steve Holden <[EMAIL PROTECTED]> writes: >> Given that Python has a 1's-complement operator already I don;t see >> why you can't just leave Python alone and use it, > >What's the meaning of the 1's complement operator (fo

Re: Possible improvement to slice opperations.

Ron Adam wrote: > Steve Holden wrote: > > >>It's a common misconception that all ideas should be explainable simply. >>This is not necessarily the case, of course. When a subject is difficult >>then all sorts of people bring their specific misconceptions to the >>topic, and suggest that if onl

Re: Possible improvement to slice opperations.

> Ron Adam wrote: > >> However, I would like the inverse selection of negative strides to be >> fixed if possible. If you could explain the current reason why it does >> not return the reverse order of the selected range. To repeat, the current reason is compatibility with the original design for

Re: Possible improvement to slice opperations.

On Mon, 5 Sep 2005 22:56:29 +0200, "Fredrik Lundh" <[EMAIL PROTECTED]> wrote: >Bengt Richter wrote: > >>>as long as you have people that insist that their original misunderstandings >>>are the only correct way to model the real world, and that all observed >>>inconsistencies in their models are ca

Re: Possible improvement to slice opperations.

Bengt Richter wrote: > On Mon, 5 Sep 2005 18:09:51 +0200, "Fredrik Lundh" <[EMAIL PROTECTED]> wrote: > OTOH, ISTM we must be careful not to label an alternate alpha-version > "way to model the real world" as a "misunderstanding" just because it is > alpha, > and bugs are apparent ;-) Thanks! I

Re: Possible improvement to slice opperations.

Steve Holden wrote: > It's a common misconception that all ideas should be explainable simply. > This is not necessarily the case, of course. When a subject is difficult > then all sorts of people bring their specific misconceptions to the > topic, and suggest that if only a few changes were ma

Re: Possible improvement to slice opperations.

Paul Rubin wrote: > Steve Holden <[EMAIL PROTECTED]> writes: > >>Given that Python has a 1's-complement operator already I don;t see >>why you can't just leave Python alone and use it, > > > What's the meaning of the 1's complement operator (for example, what > is ~1), when ints and longs are th

Re: Possible improvement to slice opperations.

Bengt Richter wrote: >>as long as you have people that insist that their original misunderstandings >>are the only correct way to model the real world, and that all observed >>inconsistencies in their models are caused by bugs in the real world, you'll >>end up with threads like this. >> > OTOH, I

Re: Possible improvement to slice opperations.

On Mon, 5 Sep 2005 18:09:51 +0200, "Fredrik Lundh" <[EMAIL PROTECTED]> wrote: >Steve Holden wrote: > >> Yes, I've been surprised how this thread has gone on and on. > >it's of course a variation of > >"You can lead an idiot to idioms, but you can't make him >think ;-)" > >as long as you ha

Re: Possible improvement to slice opperations.

Steve Holden <[EMAIL PROTECTED]> writes: > Given that Python has a 1's-complement operator already I don;t see > why you can't just leave Python alone and use it, What's the meaning of the 1's complement operator (for example, what is ~1), when ints and longs are the same? -- http://mail.python.o

Re: Possible improvement to slice opperations.

Ron Adam wrote: > However, I would like the inverse selection of negative strides to be > fixed if possible. If you could explain the current reason why it does > not return the reverse order of the selected range. why? you're not listening anyway. -- http://mail.python.org/mailman/listi

Re: Possible improvement to slice opperations.

Ron Adam wrote: > Magnus Lycka wrote: > > >>Ron Adam wrote: >> >> >>>Slicing is one of the best features of Python in my opinion, but >>>when you try to use negative index's and or negative step increments >>>it can be tricky and lead to unexpected results. >> >> >>Hm... Just as with positive ind

Re: Possible improvement to slice opperations.

Fredrik Lundh wrote: > Steve Holden wrote: > > >>Yes, I've been surprised how this thread has gone on and on. > > > it's of course a variation of > > "You can lead an idiot to idioms, but you can't make him > think ;-)" > > as long as you have people that insist that their original m

Re: Possible improvement to slice opperations.

Magnus Lycka wrote: > Ron Adam wrote: > >> Slicing is one of the best features of Python in my opinion, but >> when you try to use negative index's and or negative step increments >> it can be tricky and lead to unexpected results. > > > Hm... Just as with positive indexes, you just need to und

Re: Possible improvement to slice opperations.

Szabolcs Nagy wrote: > with the current syntax L[i:i+1] returns [L[i]], with nxlist it returns > L[i+1] if i<0. > > L=range(10) > L[1:2]==[L[1]]==[1] > L[-2:-1]==[L[-2]]==[8] > > L=nxlist(range(10)) > L[1:2]==[L[1]]==[1] > L[-2:-1]==[L[-1]]==[9] # not [L[-2]] > > IMHO in this case current list

Re: Possible improvement to slice opperations.

Steve Holden wrote: > Yes, I've been surprised how this thread has gone on and on. it's of course a variation of "You can lead an idiot to idioms, but you can't make him think ;-)" as long as you have people that insist that their original misunderstandings are the only correct way to m

Re: Possible improvement to slice opperations.

Scott David Daniels wrote: > Magnus Lycka wrote: > >> Ron Adam wrote: >> >>> ONES BASED NEGATIVE INDEXING > > > I think Ron's idea is taking off from my observation that if one's > complement, rather than negation, was used to specify measure-from- > right, we would have a simple consistent sys

Re: Possible improvement to slice opperations.

Scott David Daniels wrote: > Magnus Lycka wrote: [...] >>>The '~' is the binary not symbol which when used >>>with integers returns the two's compliment. > > Actually, the ~ operator is the one's complement operator. > Actually the two are exactly the same thing. Could we argue about substantiv

Re: Possible improvement to slice opperations.

Magnus Lycka wrote: > Ron Adam wrote: >> ONES BASED NEGATIVE INDEXING I think Ron's idea is taking off from my observation that if one's complement, rather than negation, was used to specify measure-from- right, we would have a simple consistent system (although I also observed it is far too late

Re: Possible improvement to slice opperations.

Ron Adam wrote: > Slicing is one of the best features of Python in my opinion, but > when you try to use negative index's and or negative step increments > it can be tricky and lead to unexpected results. Hm... Just as with positive indexes, you just need to understand the concept properly. > Thi

Re: Possible improvement to slice opperations.

with the current syntax L[i:i+1] returns [L[i]], with nxlist it returns L[i+1] if i<0. L=range(10) L[1:2]==[L[1]]==[1] L[-2:-1]==[L[-2]]==[8] L=nxlist(range(10)) L[1:2]==[L[1]]==[1] L[-2:-1]==[L[-1]]==[9] # not [L[-2]] IMHO in this case current list slicing is more consistent. -- http://mail.p

Re: Possible improvement to slice opperations.

Patrick Maupin wrote: >>After considering several alternatives and trying out a few ideas with a >> modified list object Bengt Richter posted, (Thank You), I think I've >>found a way to make slice operation (especially far end indexing) >>symmetrical and more consistent. > > > I don't know that

Re: Possible improvement to slice opperations.

Terry Reedy wrote: > "Ron Adam" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > >>Slicing is one of the best features of Python in my opinion, but >>when you try to use negative index's and or negative step increments >>it can be tricky and lead to unexpected results. >> >>This to

Re: Possible improvement to slice opperations.

> After considering several alternatives and trying out a few ideas with a > modified list object Bengt Richter posted, (Thank You), I think I've > found a way to make slice operation (especially far end indexing) > symmetrical and more consistent. I don't know that it makes it more consistent.

Re: Possible improvement to slice opperations.

"Ron Adam" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Slicing is one of the best features of Python in my opinion, but > when you try to use negative index's and or negative step increments > it can be tricky and lead to unexpected results. > > This topic has come up fairly oft

Possible improvement to slice opperations.

After considering several alternatives and trying out a few ideas with a modified list object Bengt Richter posted, (Thank You), I think I've found a way to make slice operation (especially far end indexing) symmetrical and more consistent. So to find out if this is indeed a possibility, it