Possible improvement to slice opperations.
steve at holdenweb.com
Tue Sep 6 02:13:42 CEST 2005
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 only a few changes were made the whole thing
>>would be easier to understand.
> What misconception do you think I have?
This was not an ad hominem attack but a commentary on many attempts to
"improve" the language.
>>Unfortunately, while that might make the topic in question easier to
>>understand for some it would make it difficult, and even
>>counter-intuitive, for others.
> True, and that's why asking and getting opinions on a subject is a good
>>As many have said before me, there's a reason why slicing and
>>indexing are the way they are. The interfaces were designed by people
>>with long years of programming and teaching experience.
> No one has yet explained the reasoning (vs the mechanics) of the
> returned value of the following.
> L = range(10)
> 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, or implied it isn't neccisary to do.
> It's quite easy to get me to change my mind on something, just show me a
> convincing explanation and I will. :)
[3, 2, 1, 0]
[3, 4, 5, 6, 7, 8, 9]
I don;t see the problem here. The start specifies which element is the
first in the slice, the stop is the default (end of the sequence) and
the stride is "successive elements to the left" when it's -1 and
"successive elements to the right" when it's 1.
Or perhaps you can tell me what I've missed?
>>You said it quite well yourself:
>>>It's easy to think you understand something when you don't. I spend
>>>quite a while figuring this out, And am sure about how it works. If
>>>there are issues with this, then it will probably be in how I describe
>>>it, what words or terminology is used, and weather or not it's the
>>>There are actually two distinct proposals here, not just one.
>>> 1. Fixing negative strides so they return the slice indexed as
>>>you say they should.
>>> 2. Using base one negative index's and picking item from the
>>>right of negative index's instead of the right.
>>>They don't both need to implemented, Item 1 could be fixed in 2.5.
>>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, since it seems to keep you
>>happy. If "fixing" item 1 in 2.5 would induce major code breakage,
>>there's less than a snowball's chance in hell it will happen.
> I doubt fixing item (1) would induce major code breakage. As near as I
> can tell, it's rarely, (nearly never), used in forms other than L[::-1].
Well, I don't see the problem yet, so I don't actually think that needs
> Item (2) however would require a lot of small changes in index's.
> Mostly changing.. L[:-1] to L[:~1] or to L[:-2]. So no, I don't expect
> one's based indexing to be added any time soon. It could be useful as a
> function or object in it's own.
My point was that you can make those changes in your own code, leaving
others to accept the situation as it is.
>>"Professor Einstein, could you tell our readers how general relativity
> Actually I can, but it would be off topic for this news group.
Right, I wasn't trying to suggest that you didn't know what you were
talking about - or even that you didn't understand general relativity
(on which my grasp could be said to be tenuous) - merely that some
things are inherently difficult, and no matter how you twist the
implementations about, the difficulties will remain.
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/
More information about the Python-list