Re: Arithmetic sequences in Python

On Mon, 23 Jan 2006 21:43:16 +1100, Steven D'Aprano <[EMAIL PROTECTED]> wrote: >On Sun, 22 Jan 2006 16:40:48 -0800, Paul Rubin wrote: > >> Steve Holden <[EMAIL PROTECTED]> writes: >>> > The current list function is supposed to be something like a >>> > typecast: >>> > >>> list() isn't a function,

Re: Arithmetic sequences in Python

On Sun, 22 Jan 2006 16:40:48 -0800, Paul Rubin wrote: > Steve Holden <[EMAIL PROTECTED]> writes: >> > The current list function is supposed to be something like a >> > typecast: >> > >> list() isn't a function, it's a type. > > I'm not sure what the distinction is supposed to be. "list" is anywa

Re: Arithmetic sequences in Python

Alex Martelli wrote: > Yep, using {} for both sets and dicts wouldn't be a good idea. I > suspect most core Python developers think of dicts as more fundamental > than sets, so... (I may disagree, but I just don't care enough about > such syntax sugar to consider even starting a debate about it on

Re: Arithmetic sequences in Python

Christoph Zwerschke <[EMAIL PROTECTED]> wrote: ... > These are valid points, but they lead me to the opposite conclusion: Why > not let {a,b,c} stand for set([a,b,c])? That would be very intuitive As syntax sugar goes, that would be on a par with the current "dict display" notation, at least.

Re: Arithmetic sequences in Python

Paul Rubin wrote: > Steve Holden <[EMAIL PROTECTED]> writes: > > > The current list function is supposed to be something like a > > > typecast: > > > > > list() isn't a function, it's a type. > > I'm not sure what the distinction is supposed to be. "list" is anyway Yo

Re: Arithmetic sequences in Python

Steve Holden <[EMAIL PROTECTED]> writes: > > The current list function is supposed to be something like a > > typecast: > > > list() isn't a function, it's a type. I'm not sure what the distinction is supposed to be. "list" is anyway callable, and lambda a:list(a) is certainly a function. > > x

Re: Arithmetic sequences in Python

Alex Martelli wrote: print set([1,2,3]) > set([1, 2, 3]) > > input and output could be identical. Do YOU have any good reason why > sets should print out as set(...) and lists should NOT print out as > list(...)? Is 'list' somehow "deeper" than 'set', to deserve a special > display-form syn

Re: Arithmetic sequences in Python

Paul Rubin wrote: > Tom Anderson <[EMAIL PROTECTED]> writes: > >>>listx/dictx/setx would be the display forms as well as the constructor forms. >> >>Could these even replace the current forms? If you want the equivalent >>of list(sometuple), write list(*sometuple). > > > The current list functi

Re: Arithmetic sequences in Python

On Sat, 21 Jan 2006, it was written: > Tom Anderson <[EMAIL PROTECTED]> writes: > >>> listx/dictx/setx would be the display forms as well as the constructor >>> forms. >> >> Could these even replace the current forms? If you want the equivalent >> of list(sometuple), write list(*sometuple). > >

Re: Arithmetic sequences in Python

Tom Anderson <[EMAIL PROTECTED]> writes: > > listx/dictx/setx would be the display forms as well as the constructor > > forms. > > Could these even replace the current forms? If you want the equivalent > of list(sometuple), write list(*sometuple). The current list function is supposed to be som

Re: Arithmetic sequences in Python

On Fri, 20 Jan 2006, it was written: > [EMAIL PROTECTED] (Alex Martelli) writes: > >>> How would you make a one-element list, which we'd currently write as >>> [3]? Would you have to say list((3,))? >> >> Yep. I don't particularly like the "mandatory trailing comma" in the >> tuple's display fo

Re: Arithmetic sequences in Python

[EMAIL PROTECTED] (Alex Martelli) writes: > > How would you make a one-element list, which we'd currently write as [3]? > > Would you have to say list((3,))? > > Yep. I don't particularly like the "mandatory trailing comma" in the > tuple's display form, mind you, but, if it's good enough for tup

Re: list(...) and list comprehensions (WAS: Arithmetic sequences in Python)

Antoon Pardon wrote: > Well we could have list(a) return [a], and have a list_from_iterable. > Although I would prefer a different name. Or reverse it - list() always takes a single iterable, and list_from_scalars() is defined something like follows: >>> def list_from_scalars(*args): retu

Re: list(...) and list comprehensions (WAS: Arithmetic sequences in Python)

Op 2006-01-18, Diez B. Roggisch schreef <[EMAIL PROTECTED]>: > Giovanni Bajo schrieb: >> Diez B. Roggisch wrote: >> due to the nested parentheses. Note that replacing list comprehensions with list(...) doesn't introduce any nested parentheses; it basically just replaces brackets wi

Re: Arithmetic sequences in Python

[EMAIL PROTECTED] (Alex Martelli) writes: > I much prefer the current arrangement where dict(a=b,c=d) means {'a':b, > 'c':d} -- it's much more congruent to how named arguments work for every > other case. Would you force us to quote argument names in EVERY > functioncall...?! Ehh, ok. There coul

Re: Arithmetic sequences in Python

How about this hack: >>> import types >>> class lazy_range(object): ... def __getitem__(self, l): ... start = l[0] ... ... if isinstance(l[1], types.EllipsisType): ... step = 1 ... if len(l) > 2: ... stop = l[2] ... else: ...

Re: Arithmetic sequences in Python

Steven D'Aprano wrote: > Steven Bethard wrote: > >> I'm not sure I find it truly hateful, but definitely unnecessary. >> TOOWTDI and all... > [snip] > > Even when people mean One Obvious and not Only One, it is still harmful > because the emphasis is wrong. The emphasis is on the *restrictive

Re: Arithmetic sequences in Python

Alex Martelli wrote: > Do YOU have any good reason why > sets should print out as set(...) and lists should NOT print out as > list(...)? Is 'list' somehow "deeper" than 'set', to deserve a special > display-form syntax which 'set' doesn't get? Or are you enshrining a > historical accident to th

Re: Arithmetic sequences in Python

Paul Rubin wrote: > [EMAIL PROTECTED] (Alex Martelli) writes: >>I see no credibly simple and readable alternative to {a:b, c:d} >>dictionary display syntax, for example; dict(((a,b),(c,d))) just >>wouldn't cut it, because of the "parentheses overload" (double >>entendre intended). > > > dict(a=b,

Re: Arithmetic sequences in Python

Steven D'Aprano wrote: > > I much prefer the current arrangement where dict(a=b,c=d) means {'a':b, > > 'c':d} -- it's much more congruent to how named arguments work for every > > other case. Would you force us to quote argument names in EVERY > > functioncall...?! > > Hmmm... should these two fo

Re: Arithmetic sequences in Python

Alex Martelli wrote: > I much prefer the current arrangement where dict(a=b,c=d) means {'a':b, > 'c':d} -- it's much more congruent to how named arguments work for every > other case. Would you force us to quote argument names in EVERY > functioncall...?! Hmmm... should these two forms give dif

Re: Arithmetic sequences in Python

Antoon Pardon <[EMAIL PROTECTED]> writes: > And [[3]] would have to become: >list((list((3,)),)) > In my opinion the bracket notation wins the clarity contest > handsdown in this case and IMO these cases occure frequently > enough. I'm convinced now. Until that, I could have gone either way.

Re: Arithmetic sequences in Python

Op 2006-01-19, Alex Martelli schreef <[EMAIL PROTECTED]>: >> What should list(list(1,2,3)) be? Should "list" really work >> completely differently depending on whether it has a single arg or >> multiple args? > > It works just fine for max and min, why should list be different? Well IMO it works

Re: Arithmetic sequences in Python

Paul Rubin wrote: ... > What should the output of "print list(1,2,3)" be? Is there a really > good reason to make it different from the input syntax? If we assume that str and repr must keep coinciding for lists (and why not), no reason -- just like, say, today: >>>

Re: Arithmetic sequences in Python

[EMAIL PROTECTED] (Alex Martelli) writes: > > Well, [...] notation for regular lists (as opposed to list > > comprehensions) is also unnecessary since we could use "list((a,b,c))". > > Indeed, there's no reason list couldn't accept multiple arguments as an > alternative to one sequence argument, j

Re: Arithmetic sequences in Python

Steven Bethard wrote: > I'm not sure I find it truly hateful, but definitely unnecessary. > TOOWTDI and all... TOOWTDI Considered Harmful. There is confusion between "There's Only One Way To Do It" and "There's One Obvious Way To Do It". The first is pejorative, harmful if it were true but st

Re: Arithmetic sequences in Python

Alex Martelli wrote: > Paul Rubin wrote: >... > > Well, [...] notation for regular lists (as opposed to list > > comprehensions) is also unnecessary since we could use "list((a,b,c))". > [snip] ... or should that be list(snip)? > But > list has no such problem, a

Re: Arithmetic sequences in Python

Paul Rubin wrote: ... > Well, [...] notation for regular lists (as opposed to list > comprehensions) is also unnecessary since we could use "list((a,b,c))". Indeed, there's no reason list couldn't accept multiple arguments as an alternative to one sequence argument, j

Re: list(...) and list comprehensions (WAS: Arithmetic sequences in Python)

Steve Holden schrieb: > Diez B. Roggisch wrote: >>> due to the nested parentheses. Note that replacing list >>> comprehensions with list(...) doesn't introduce any nested >>> parentheses; it basically just replaces brackets with parentheses. >> >> >> But you don't need the nested parentheses - u

Re: list(...) and list comprehensions (WAS: Arithmetic sequences in Python)

Giovanni Bajo schrieb: > Diez B. Roggisch wrote: > >>> due to the nested parentheses. Note that replacing list comprehensions >>> with list(...) doesn't introduce any nested parentheses; it basically >>> just replaces brackets with parentheses. >> But you don't need the nested parentheses - use *

Re: list(...) and list comprehensions (WAS: Arithmetic sequences in Python)

Diez B. Roggisch wrote: >>due to the nested parentheses. Note that replacing list comprehensions >>with list(...) doesn't introduce any nested parentheses; it basically >>just replaces brackets with parentheses. > > > But you don't need the nested parentheses - use *args instead for the > lis

Re: list(...) and list comprehensions (WAS: Arithmetic sequences in Python)

Diez B. Roggisch wrote: >> due to the nested parentheses. Note that replacing list comprehensions >> with list(...) doesn't introduce any nested parentheses; it basically >> just replaces brackets with parentheses. > > But you don't need the nested parentheses - use *args instead for the > list-c

Re: list(...) and list comprehensions (WAS: Arithmetic sequences in Python)

> due to the nested parentheses. Note that replacing list comprehensions > with list(...) doesn't introduce any nested parentheses; it basically > just replaces brackets with parentheses. But you don't need the nested parentheses - use *args instead for the list-constructor. list(a,b,c) Apar

list(...) and list comprehensions (WAS: Arithmetic sequences in Python)

Tom Anderson <[EMAIL PROTECTED]> wrote: > Sounds good. More generally, i'd be more than happy to get rid of list > comprehensions, letting people use list(genexp) instead. That would > obviously be a Py3k thing, though. Alex Martelli wrote: > I fully agree, but the BDFL has already (tentativel

Re: Arithmetic sequences in Python

Steven Bethard <[EMAIL PROTECTED]> writes: > > I fully agree, but the BDFL has already (tentatively, I hope) > > Pronounced > > that the [...] form will stay in Py3K as syntax sugar for list(...). > > I find that to be a truly hateful prospect > > I'm not sure I find it truly hateful, but definit

Re: Arithmetic sequences in Python

Alex Martelli wrote: > Tom Anderson <[EMAIL PROTECTED]> wrote: >> Sounds good. More generally, i'd be more than happy to get rid of list >> comprehensions, letting people use list(genexp) instead. That would >> obviously be a Py3k thing, though. > > I fully agree, but the BDFL has already (tentat

Re: Arithmetic sequences in Python

Op 2006-01-16, Gregory Petrosyan schreef <[EMAIL PROTECTED]>: > 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 slig

Re: Arithmetic sequences in Python

Op 2006-01-18, Tom Anderson schreef <[EMAIL PROTECTED]>: > On Tue, 17 Jan 2006, Antoon Pardon wrote: > >> Op 2006-01-16, Alex Martelli schreef <[EMAIL PROTECTED]>: >>> Paul Rubin wrote: >>> Steven D'Aprano <[EMAIL PROTECTED]> writes: > For finite sequences, your

Re: Arithmetic sequences in Python

Op 2006-01-17, Gregory Petrosyan schreef <[EMAIL PROTECTED]>: > Hey guys, this proposal has already been rejected (it is the PEP 204). > No it isn't. In my proposal [1, 2:8, 8] would be equivallent to [1, slice(2,8), 8]. If someone would want the list [1,2,3,4,5,6,7,8] with this notation, I would

Re: Arithmetic sequences in Python

Op 2006-01-17, Steven Bethard schreef <[EMAIL PROTECTED]>: > Antoon Pardon wrote: >> Why don't we give slices more functionality and use them. >> These are a number of ideas I had. (These are python3k ideas) >> >> 1) Make slices iterables. (No more need for (x)range) >> >> 2) Use a bottom and sto

Re: Arithmetic sequences in Python

Tom Anderson <[EMAIL PROTECTED]> wrote: ... > Sounds good. More generally, i'd be more than happy to get rid of list > comprehensions, letting people use list(genexp) instead. That would > obviously be a Py3k thing, though. I fully agree, but the BDFL has already (tentatively, I hope) Pronounc

Re: Arithmetic sequences in Python

Gregory Petrosyan wrote: > Hey guys, this proposal has already been rejected (it is the PEP 204). No, this is a subtly different proposal. Antoon is proposing *slice* literals, not *range* literals. Note that "confusion between ranges and slice syntax" was one of the reasons for rejection of `

Re: Arithmetic sequences in Python

Paul Rubin wrote: > I don't think this is a valid objection. Python is already full of > syntactic sugar like indentation-based block structure, infix > operators, statements with keyword-dependent syntax, etc. It's that > very sugar that attracts programmers to Python away from comparatively > s

Re: Arithmetic sequences in Python

On Tue, 17 Jan 2006, Antoon Pardon wrote: > Op 2006-01-16, Alex Martelli schreef <[EMAIL PROTECTED]>: >> Paul Rubin wrote: >> >>> Steven D'Aprano <[EMAIL PROTECTED]> writes: For finite sequences, your proposal adds nothing new to existing solutions like range a

Re: Arithmetic sequences in Python

On Tue, 16 Jan 2006, it was written: > Tom Anderson <[EMAIL PROTECTED]> 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 >> Ro

Re: Arithmetic sequences in Python

Hey guys, this proposal has already been rejected (it is the PEP 204). -- http://mail.python.org/mailman/listinfo/python-list

Re: Arithmetic sequences in Python

Antoon Pardon wrote: > Why don't we give slices more functionality and use them. > These are a number of ideas I had. (These are python3k ideas) > > 1) Make slices iterables. (No more need for (x)range) > > 2) Use a bottom and stop variable as default for the start and >stop attribute. top wo

Re: Arithmetic sequences in Python

Hmm, and why not? Or you realy hate such behaviour? Note, everything I post here is just some ideas I want to discuss, and to make these ideas better after discussion. And this particular idea needs to be discussed, too. -- http://mail.python.org/mailman/listinfo/python-list

Re: Arithmetic sequences in Python

"Gregory Petrosyan" <[EMAIL PROTECTED]> writes: > 2) [5 .. 0] -> [5,4,3,2,1,0] > So, if "next" is omited, let the default step be 1 if "first" < "last" > and -1 otherwise. So what do you want [a..b] to do? Dynamically decide what direction to go? Ugh! -- http://mail.python.org/mailman/listinfo/

Re: Arithmetic sequences in Python

Op 2006-01-16, Alex Martelli schreef <[EMAIL PROTECTED]>: > Paul Rubin wrote: > >> Steven D'Aprano <[EMAIL PROTECTED]> writes: >> > For finite sequences, your proposal adds nothing new to existing >> > solutions like range and xrange. >> >> Oh come on, [5,4,..0] is much

Re: Arithmetic sequences in Python

Some ideas: 1) Let [a,b .. c] be *ordinary list* ! Just like [1,2,3]. Are there any questions why 3 is included in [1,2,3]? IMO it's more correct to think about [first, next .. last] as about syntax for list creation, but not as about "syntax-to-replace-range-function". (And, because it's an ordi

Re: Arithmetic sequences in Python

Dennis Lee Bieber <[EMAIL PROTECTED]> 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 t

Re: Arithmetic sequences in Python

Tom Anderson <[EMAIL PROTECTED]> 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 20

Re: Arithmetic sequences in Python

On Mon, 16 Jan 2006, Alex Martelli wrote: > Steven D'Aprano <[EMAIL PROTECTED]> 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), >>> (f

Re: Arithmetic sequences in Python

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

Re: Arithmetic sequences in Python

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'..'zyzzogeton'] be? tom -- Socialism - straight in the mainline! -- http://mail.python.org/mailman/listinfo/python-list

Re: Arithmetic sequences in Python

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 in

Re: Arithmetic sequences in Python

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 in

Re: Arithmetic sequences in Python

"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

Re: Arithmetic sequences in Python

"Gregory Petrosyan" <[EMAIL PROTECTED]> 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.

Re: Arithmetic sequences in Python

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 ar

Re: Arithmetic sequences in Python

Thanks for your replies. So, some problems and possible solutions: 1) [f(n), f(n)-1 .. 0] can be easily catched by interpreter, and f(n) can be evaluated only once. 2) if you need right border excluded, I think [0 .. n) is very clear (and consistent with mathematics). And about brakets highlighti

Re: Arithmetic sequences in Python

Xavier Morel <[EMAIL PROTECTED]> writes: > The only thing that bothers me about the initial proposal is that > there would not, in fact, be any "range object", but merely a > syntactic sugar for list/generator creation. Well, it could create something like an xrange. Maybe that's preferable. >

Re: Arithmetic sequences in Python

[EMAIL PROTECTED] (Alex Martelli) writes: > > Oh come on, [5,4,..0] is much easier to read than range(5,-1,-1). > > But not easier than reversed(range(6)) Heh, I like that, and reversed(xrange(6)) appears to do the right thing too. I didn't know about __reversed__ before. > [[the 5 in one of t

Re: Arithmetic sequences in Python

i would love to see a nice, clear syntax instead of for i in xrange(start, stop, step): ... because xrange is ugly and iteration over int sequences are important. we don't need a range() alternative ( [0:10] or [0..10] ) (because no one would ever use range() if there were a nice integer-for-loop)

Re: Arithmetic sequences in Python

In <[EMAIL PROTECTED]>, Roy Smith wrote: > Alex Martelli <[EMAIL PROTECTED]> wrote: >>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=True). > > How about... > > for i in (0..x]: >

Re: Arithmetic sequences in Python

Roy Smith <[EMAIL PROTECTED]> wrote: > Alex Martelli <[EMAIL PROTECTED]> wrote: > >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=True). > > How about... > > for i in (0..x]: >

Re: Arithmetic sequences in Python

Alex Martelli <[EMAIL PROTECTED]> wrote: >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=True). How about... for i in (0..x]: blah -- http://mail.python.org/mailman/listinfo/py

Re: Arithmetic sequences in Python

On Mon, 16 Jan 2006 02:58:39 -0800, Paul Rubin wrote: > Steven D'Aprano <[EMAIL PROTECTED]> writes: >> For finite sequences, your proposal adds nothing new to existing >> solutions like range and xrange. > > Oh come on, [5,4,..0] is much easier to read than range(5,-1,-1). Only in isolation, and

Re: Arithmetic sequences in Python

Steven D'Aprano <[EMAIL PROTECTED]> 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 w

Re: Arithmetic sequences in Python

Paul Rubin wrote: > Steven D'Aprano <[EMAIL PROTECTED]> writes: > > For finite sequences, your proposal adds nothing new to existing > > solutions like range and xrange. > > Oh come on, [5,4,..0] is much easier to read than range(5,-1,-1). But not easier than reversed(

Re: Arithmetic sequences in Python

Paul Rubin wrote: ... > while the traditional > > xrange(f(n)-1, -1, -1) > > only evaluates it once but is IMO repulsive. Yep, reversed(range(f(n))) is MUCH better. Alex -- http://mail.python.org/mailman/listinfo/python-list

Re: Arithmetic sequences in Python

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)

Re: Arithmetic sequences in Python

Ranges of letters are quite useful, they are used a lot in Delphi/Ada languages: "a", "b", "c", "d", "e"... I like the syntax [1..n], it looks natural enough to me, but I think the Ruby syntax with ... isn't much natural. To avoid bugs the following two lines must have the same meaning: [1..n-1] [

Re: Arithmetic sequences in Python

Paul Rubin wrote: > There's something to be said for that. Should ['a'..'z'] be a list or > a string? To me, the most obvious result would be either a range object as a result, or always a list/generator of objects (to stay perfectly consistent). If a range of numbers translate into a list of nu

Re: Arithmetic sequences in Python

Steven D'Aprano <[EMAIL PROTECTED]> writes: > For finite sequences, your proposal adds nothing new to existing > solutions like range and xrange. Oh come on, [5,4,..0] is much easier to read than range(5,-1,-1). > The only added feature this proposal > introduces is infinite iterators, and they a

Re: Arithmetic sequences in Python

On Mon, 16 Jan 2006 01:01:39 -0800, 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. So, maybe > there's a reason to adopt sli

Re: Arithmetic sequences in Python

_Consistentsy_ is what BDFL rejects, if I understand pep right. As for me, it's not too god to have similar syntax for really different tasks. And [1:10] is really not obvious, while [1..10] is. -- http://mail.python.org/mailman/listinfo/python-list

Re: Arithmetic sequences in Python

"Gregory Petrosyan" <[EMAIL PROTECTED]> writes: > 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? I like this with some issues: Python loops te

Re: Arithmetic sequences in Python

I like the use of the colon as in the PEP better: it is consistant with the slice notation and also with the colon operator in Matlab. I like the general idea and I would probably use it a lot if available, but the functionality is already there with range and irange. Bas -- http://mail.python.

Arithmetic sequences in Python

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,