number ranges

[Colin J. Williams]

Alex Martelli wrote:
> Steven D'Aprano <steve at REMOVEMEcyber.com.au> wrote:
>    ...
> 
>>>Reread the part I quoted above: at least some of the proponents of this
>>>syntax appear to be totally ignorant of 30 years of literature and
>>>practice of programming, "it will be tough to convince" them that closed
>>>intervals are a terrible mistake and semi-open ones the only way to go.
>>
>>I intellectually understand that semi-open intervals 
>>are the only way to go. But reading the words, the part 
>>of my brain that speaks English cries out for a closed 
>>interval. Bad brain.
> 
> 
> Human brain -- it's harder for non-native-speakers like me to judge the
> associations of certain English words in a native speaker's brain.
> 
> 
>>Given the overwhelming benefit of semi-closed 
>>intervals, I wish to amend my proposal to follow Alex's 
>>suggestions, namely:
>>
>>for i in (1 to 10 by 3):
>>     print i
>>
>>should print 1 4 7.
> 
> 
> But that would be an "attractive nuisance" to many other native speakers
> like you, who would instinctively think of a closed interval.  Maybe
> 'upto' rather than 'to', as somebody else suggested, would ease that.
> 
> 
>>That would make (a to b by c) equivalent to 
>>range(a,b,c) except that it returns an iterator rather 
>>than a list. Hmmm... putting it that way, the new 
>>syntax actually costs 1 keystroke, or saves 1 if you 
>>put spaces after the commas in the range expression. 
>>Does it add enough clarity and ease of understanding to 
>>justify two new keywords?
> 
> 
> No, of course not.  And if we use upto, we'll need a downto as well, a
> third keyword, for loops with negative step.  range should return an
> iterator in Python 3.0 (maybe in 2010?-) and xrange will then go away,
> so the only issue is whether syntax sugar for it is SO badly needed as
> to justify 2/3 new keywords.
> 
> 
>>>whines about it); Python is clearly much better off if such people run
>>>away to Ruby, with its (expletive deleted) a..b AND a...b syntaxes just
>>>to ensure maximum confusion;-).
>>
>>Ruby uses both .. and ...? Now I'm frightened.
> 
> 
> I _like_ Ruby, mostly, but yes, it has both a..b AND a...b, one of them
> to indicate a semi-open interval and the other to indicate a closed one
> (I believe the three dots are for the semi-open, but it could be the
> other way 'round) -- I don't remember how it indicates a step. I do
> think this is a wart (lack of visual or mnemonic distinction), though
> I'm sure Ruby enthusiasts would not agree.
> 
> 
> Alex
http://www.ruby-doc.org/docs/ProgrammingRuby/
It seems that .. and ... are Range class constructors.

Range.new(a, b, exclusive= True) is equivalent to Python's range(a, b) 
i.e. Ruby's  a...b

There appears to be no provision for a stride.

Ruby's choice between .. and ... seems a little perverse.  I would 
expect '...' to deliver a little more than '..'.

I guess one could consider Python's range() as a constructor for the 
List class.

Steven D'Aprano suggested that 1 to 10 by 3 should create an iterator.
What are the benefits of this as compared with a Python List?

Could we not have 1 ... 10 ... 3 to mean the same thing and then there 
would be no need for extra reserved words?

Colin W.