Arithmetic sequences in Python

[Gregory Petrosyan]

Please visit http://www.python.org/peps/pep-0204.html first.

As you can see, PEP 204 was rejected, mostly because of not-so-obvious
syntax. But IMO the idea behind this pep is very nice. So, maybe
there's a reason to adopt slightly modified Haskell's syntax? Something
like

[1,3..10] --> [1,3,5,7,9]
(1,3..10) --> same values as above, but return generator instead of
list
[1..10] --> [1,2,3,4,5,6,7,8 ,9,10]
(1 ..) --> 'infinite' generator that yield 1,2,3 and so on
(-3,-5 ..) --> 'infinite' generator that yield -3,-5,-7 and so on

So,
1) "[]" means list, "()" means generator
2) the "start" is required, "step" and "end" are optional.

Also, this can be nicely integrated with enumerations (if they will
appear in python). Haskell is also example of such integration.

[Gregory Petrosyan]

Steven D'Aprano wrote:

Python indexing deliberately goes to one-past-the-end counting for a
reason: it helps prevent off-by-one signpost errors. This syntax goes
against that decision, and adds one more thing to memorise about Python:
the end index is not included in the list, except for arithmetic
sequences, where it is, sometimes but not necessarily. In [5,6,10] the end
index 10 is included; in [5,7,10] it isn't.

1) both in [5,6,10] and [5,7,10] 10 is included ;-)
And as for [5,6 .. 10] and [5,7 .. 10]... First one should look
like [5 .. 10] I think. But you are right:
it looks like a problem that in one case 10 is included and in
other not. I should think about it.

2) I think there's nothing to memorise: in mathematics [1,2 .. 10]
includes 10, almost everybody knows
it.
The thing that newcomer should memorise is (IMHO) _not_so_obvious _
behaviour of 'range'. You
may laugh at me, if you want. But look at Cormen's pseudocode: "for
j=1 to n" includes 'n'. (And
indexing starts from 1, not from 0, but that's another story).
Also, for non-programmer including the
borders is obvious, not otherwise.

[Paul Rubin]

"Gregory Petrosyan" <gr************ ***@gmail.com> writes:

1) both in [5,6,10] and [5,7,10] 10 is included ;-)
And as for [5,6 .. 10] and [5,7 .. 10]... First one should look
like [5 .. 10] I think. But you are right:
it looks like a problem that in one case 10 is included and in
other not. I should think about it.

[5,7 .. 10] means [5,7,9,11,13,15, ... ] limited to x<=10, so that
means [5,7,9]. 10 is not included.

[Paul Rubin]

"Gregory Petrosyan" <gr************ ***@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 counterintuitiv e 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'.

[Xavier Morel]

Steven D'Aprano wrote:

On Mon, 16 Jan 2006 12:51:58 +0100, Xavier Morel wrote:

For those who'd need the (0..n-1) behavior, Ruby features something that
I find quite elegant (if not perfectly obvious at first), (first..last)
provides a range from first to last with both boundaries included, but
(first...last) (notice the 3 periods)

No, no I didn't.

Sheesh, that just *screams* "Off By One Errors!!!". Python deliberately
uses a simple, consistent system of indexing from the start to one past
the end specifically to help prevent signpost errors, and now some folks
want to undermine that.

*shakes head in amazement*

Steven, I never said that Python should use this syntax, I merely showed
how it was done in Ruby.

It's nothing more than a ... basis of discussion... not a "I want that
!!ONE" post (if I did, i'd be using Ruby and posting on c.l.r)

(and you didn't what by the way?)

Ok scratch that, you didn't notice the 3 periods.

[Xavier Morel]

Steven D'Aprano wrote:

On Mon, 16 Jan 2006 12:51:58 +0100, Xavier Morel wrote:

For those who'd need the (0..n-1) behavior, Ruby features something that
I find quite elegant (if not perfectly obvious at first), (first..last)
provides a range from first to last with both boundaries included, but
(first...last) (notice the 3 periods)

No, no I didn't.

Sheesh, that just *screams* "Off By One Errors!!!". Python deliberately
uses a simple, consistent system of indexing from the start to one past
the end specifically to help prevent signpost errors, and now some folks
want to undermine that.

*shakes head in amazement*

Steven, I never said that Python should use this syntax, I merely showed
how it was done in Ruby.

It's nothing more than a ... basis of discussion... not a "I want that
!!ONE" post (if I did, i'd be using Ruby and posting on c.l.r)

(and you didn't what by the way?)

[Tom Anderson]

On Mon, 16 Jan 2006, it was written:

There's something to be said for that. Should ['a'..'z'] be a list or a
string?

And while we're there, what should ['aa'..'zyzzoget on'] be?

tom

--
Socialism - straight in the mainline!

[Tom Anderson]

On Mon, 16 Jan 2006, Gregory Petrosyan wrote:

Please visit http://www.python.org/peps/pep-0204.html first.

As you can see, PEP 204 was rejected, mostly because of not-so-obvious
syntax. But IMO the idea behind this pep is very nice.
Agreed. Although i have to say, i like the syntax there - it seems like a
really natural extension of existing syntax.
So, maybe there's a reason to adopt slightly modified Haskell's syntax?
Well, i do like the .. - 1..3 seems like a natural way to write a range.
I'd find 1...3 more natural, since an ellipsis has three dots, but it is
slightly more tedious.

The natural way to implement this would be to make .. a normal operator,
rather than magic, and add a __range__ special method to handle it. "a ..
b" would translate to "a.__range__(b) ". I note that Roman Suzi proposed
this back in 2001, after PEP 204 was rejected. It's a pretty obvious
implementation, after all.
Something like

[1,3..10] --> [1,3,5,7,9]
(1,3..10) --> same values as above, but return generator instead of
list
[1..10] --> [1,2,3,4,5,6,7,8 ,9,10]
(1 ..) --> 'infinite' generator that yield 1,2,3 and so on
(-3,-5 ..) --> 'infinite' generator that yield -3,-5,-7 and so on
-1. Personally, i find the approach of specifying the first two elements
*absolutely* *revolting*, and it would consistently be more awkward to use
than a start/step/stop style syntax. Come on, when do you know the first
two terms but not the step size?
1) "[]" means list, "()" means generator

Yuck. Yes, i know it's consistent with list comps and genexps, but yuck to
those too!

Instead, i'd like to see lazy lists used here - these look like lists, and
can be used exactly like a list, but if all you want to do is iterate over
them, they don't need to instantiate themselves in memory, so they're as
efficient as an iterator. The best of both worlds! I've written a sketch
of a generic lazy list:

http://urchin.earth.li/~twic/lazy.py

Note that this is what xrange does already (as i've just discovered).

tom

--
Socialism - straight in the mainline!

[Tom Anderson]

On Mon, 16 Jan 2006, Alex Martelli wrote:

Steven D'Aprano <st***@REMOVETH IScyber.com.au> wrote:

On Mon, 16 Jan 2006 12:51:58 +0100, Xavier Morel wrote:

For those who'd need the (0..n-1) behavior, Ruby features something
that I find quite elegant (if not perfectly obvious at first),
(first..last) provides a range from first to last with both boundaries
included, but (first...last) (notice the 3 periods)

No, no I didn't.

Sheesh, that just *screams* "Off By One Errors!!!". Python deliberately
uses a simple, consistent system of indexing from the start to one past
the end specifically to help prevent signpost errors, and now some
folks want to undermine that.

*shakes head in amazement*

Agreed. *IF* we truly needed an occasional "up to X *INCLUDED*"
sequence, it should be in a syntax that can't FAIL to be noticed, such
as range(X, endincluded=Tru e).

How about first,,last? Harder to do by mistake, but pretty horrible in its
own way.

tom

--
Socialism - straight in the mainline!

[Paul Rubin]

Tom Anderson <tw**@urchin.ea rth.li> writes:

The natural way to implement this would be to make .. a normal
operator, rather than magic, and add a __range__ special method to
handle it. "a .. b" would translate to "a.__range__(b) ". I note that
Roman Suzi proposed this back in 2001, after PEP 204 was
rejected. It's a pretty obvious implementation, after all.

Interesting, but what do you do about the "unary postfix" (1 ..)
infinite generator?

(-3,-5 ..) --> 'infinite' generator that yield -3,-5,-7 and so on

-1. Personally, i find the approach of specifying the first two
elements *absolutely* *revolting*, and it would consistently be more
awkward to use than a start/step/stop style syntax. Come on, when do
you know the first two terms but not the step size?

Usually you know both, but showing the first two elements makes
sequence more visible. I certainly like (1,3..9) better than (1,9;2)
or whatever.

1) "[]" means list, "()" means generator

Yuck. Yes, i know it's consistent with list comps and genexps, but
yuck to those too!

I'd be ok with getting rid of [] and just having generators or
xrange-like class instances. If you want to coerce one of those to a
list, you'd say list((1..5)) instead of [1..5].

[Paul Rubin]

Dennis Lee Bieber <wl*****@ix.net com.com> writes:

What would be expected from
[1, 3, 6 .. 20]
???
In Haskell:

Hugs.Base> [1,3,6..20]
ERROR - Syntax error in expression (unexpected `..')
Hugs.Base>
Again, I see [1, 3, 6, 7, 8, 9, 10, ... , 18, 19]

You'd write that in Haskell as 1:3:[6..19]. In Python I guess
you'd say [1,3]+[6..19].