"Gregory Petrosyan" <[EMAIL PROTECTED]> 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'.
--
http://mail.python.org/mailman/listinfo/python-list
