Arithmetic sequences in Python

[Paul Rubin]

"Gregory Petrosyan" <gregory.petrosyan at gmail.com> writes:
> 1) [f(n), f(n)-1 .. 0] can be easily catched by interpreter, and f(n)
> can be evaluated only once.

I think it would be counterintuitive for the interpreter to do that.
If I type f(n) twice I expect it to be evaluated twice.

> 2) if you need right border excluded, I think [0 .. n) is very clear
> (and consistent with mathematics).

Oh man, that's really ugly.  I'm not crazy about Ruby's "..." either
though I guess it's ok.  Using colon for non-inclusion might be more
Python-like since it resembles both the syntax and behavior of an
existing python range:

  [0.. : n]  

(hmm, it does look kind of ugly).

> 3) Of course, in some cases 'range' is more readable. As for your
> examples:
> 
> [0,..9] versus range(10)
> [55, ...73] versus range(55, 74)
> [1, 3, ..len(mystr)] versus range(1, len(mystr)+1, 2)
> [55, 65, 295] versus range(55, 296, 10)

Those examples should be written:

  [0 .. 9] versus range(10)
  [55 .. 73] versus range(55,74)
  [1, 3, .. len(mystr)] versus range(1, len(mystr)+1, 2)
  [55, 65, .. 295] versus range(55, 296, 10)

I find the ".." version more readable than the "range" version for
all four cases.  YMMV.

> 4) Proposed syntax can be easily extended to support chars (or any
> other enumeration). (Maybe, without _implied_ :-) step parameter):
> 
> ['a' .. 'd']  -> ['a','b','c','d'] (let it be a list for consistency)

Hmm:

    Hugs.Base> ['a'..'d']
    "abcd"
    Hugs.Base>

Note that "abcd" in Haskell is actually a list of chars.

> ('a' ..)      -> generator that yields english alphabet

I think this has to be an infinite generator or one that yields all
the ascii chars starting with 'a'.