Grouping code by indentation - feature or ******?

Steve Holden steve at holdenweb.com
Fri Apr 1 18:54:57 EST 2005


Javier Bezos wrote:
> "Myles Strous" <myles at .com> escribió en el mensaje
> news:1112162883.943233.37980 at o13g2000cwo.googlegroups.com...
> 
>>>>satisfy some handy properties, the first of which being:
>>>>  l[:n] + l[n:] = l
>>>
>>>I don't think l[:5] + l[5:] = l is a handy property
>>>and to me is clearly counterintuitive. Further,
>>
>>It can be quite useful for inserting something into a list (or string),
>>after finding the position where you wish to insert it.
>>improvedList = l[:n] + [new stuff] + l[n:]
> 
> 
> As I answered in another post this is not more
> useful than writing l[:n-1]. Of course, I'm aware
> of the case where n=0, but this would require only
> a bit of extra code (and, after all, I'm just saying
> that half-open ranges are not a panacea and that I
> don't like their side effects).
> 
> 
>>I vaguely remember hearing at one stage that the
>>sequence[position:position+length] notation is also potentially useful
>>for indexing into large strings or buffers.
> 
> 
> Right, to some extent it's useful, but at the cost
> of introducing tricky syntaxes for very specific
> cases, like this one, and unexpected off-by-one
> errors in other cases, which is my point. For
> example, recently I had to get a value from a
> list preceded by the two previous values:
> lst[n-2:n+1] and not the more logical (at last
> to my eyes) lst[n-2:n].
> 
> Instead of giving further examples I would like
> to cite three cases:
> 
> 1) You have a starting point (s) and a
>    length (t): lst[s:s+t].
> 2) You have an ending point (e) and a
>    length: lst[e-t+1:e+1].
> 3) You have a starting point and an ending
>    point: lst[s:e+1].
> 
> What's odd is that Python applies the syntax of
> case 3 to the logic of case 1. While something
> like lst[s:s+t-1] for the first case could be
> explained in simple mathematical terms (in other
> words, it's an integral part of the algorithms),
> I cannot find a way to explain the e+1 in cases
> 2 and 3 (and the inconsistency with e-t+1 in case
> 2 vs. s+t in case 1) except the Python syntax.
> 

While this may be an interesting philosophical (or should that be 
philological) discussion, since Python has worked this way for donkey's 
years, and since a change would break 30% of the existing codebase, you 
clearly can't be advocating change.

So, what's the point of this thread now?

regards
  Steve
-- 
Steve Holden        +1 703 861 4237  +1 800 494 3119
Holden Web LLC             http://www.holdenweb.com/
Python Web Programming  http://pydish.holdenweb.com/




More information about the Python-list mailing list