471,579 Members | 1,270 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,579 software developers and data experts.

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

Tom Anderson <tw**@urchin.earth.li> 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 (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, but that's the
prospect:-(.
Steven Bethard wrote: I'm not sure I find it truly hateful, but definitely unnecessary.
TOOWTDI and all...
Paul Rubin wrote: Well, [...] notation for regular lists (as opposed to list
comprehensions) is also unnecessary since we could use
"list((a,b,c))".


I'm not sure that's really a fair comparison. Do you really find:

list(x**2 for x in iterable)

harder to read than:

[x**2 for x in iterable]

?? I don't, though perhaps this is just me. OTOH, I do find:

list((a, b, c))

to be substantially harder to read than:

[a, b, c]

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.

Just in case there was any confusion, I definitely wasn't suggesting
that we remove list literal support.

STeVe
Jan 18 '06 #1
7 1501
> 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)

Apart from that, I hope that the [] stay in. After all, if they are kept
around for literal list construction, the aren't free for other purposes
anyway.

Regards,

Diez
Jan 18 '06 #2
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-constructor.

list(a,b,c)


No, you can't. That's ambigous if you pass only one argument, and that
argument is iterable. This is also the reason why set() doesn't work this
way.
--
Giovanni Bajo
Jan 18 '06 #3
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-constructor.

list(a,b,c)

Apart from that, I hope that the [] stay in. After all, if they are kept
around for literal list construction, the aren't free for other purposes
anyway.
list(1,2,3) Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: list() takes at most 1 argument (3 given)


So you're talking about the way list() *should* work in Python 3, right?

regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/

Jan 18 '06 #4
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 *args instead for the
list-constructor.

list(a,b,c)


No, you can't. That's ambigous if you pass only one argument, and that
argument is iterable. This is also the reason why set() doesn't work this
way.


Ah, you're right - I thought about the >1 case, but not that one.

Regards,

Diez
Jan 18 '06 #5
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 - use *args instead for the
list-constructor.

list(a,b,c)

Apart from that, I hope that the [] stay in. After all, if they are
kept around for literal list construction, the aren't free for other
purposes anyway.
>>> list(1,2,3) Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: list() takes at most 1 argument (3 given) >>>


So you're talking about the way list() *should* work in Python 3, right?


Yes, should have said "could" there. But as Giovanni pointed out I
missed the ambiguity in case of the size one lists.

Diez
Jan 18 '06 #6
Op 2006-01-18, Diez B. Roggisch schreef <de***@nospam.web.de>:
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 *args instead for the
list-constructor.

list(a,b,c)


No, you can't. That's ambigous if you pass only one argument, and that
argument is iterable. This is also the reason why set() doesn't work this
way.


Ah, you're right - I thought about the >1 case, but not that one.


Well we could have list(a) return [a], and have a list_from_iterable.
Although I would prefer a different name.

--
Antoon Pardon
Jan 20 '06 #7
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): return list(args)
print list_from_scalars(1,2,3) [1, 2, 3] print list_from_scalars('a') ['a']

Jan 20 '06 #8

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

42 posts views Thread by Bicho Verde | last post: by
176 posts views Thread by Thomas Reichelt | last post: by
25 posts views Thread by Haines Brown | last post: by
72 posts views Thread by Gregory Petrosyan | last post: by
4 posts views Thread by Army1987 | last post: by
1 post views Thread by mmm | last post: by
reply views Thread by XIAOLAOHU | last post: by
reply views Thread by leo001 | last post: by
reply views Thread by lumer26 | last post: by
1 post views Thread by lumer26 | last post: by
reply views Thread by lumer26 | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.