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

[Steven Bethard]

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

[Diez B. Roggisch]

> 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

[Giovanni Bajo]

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

[Steve Holden]

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 [phone] [phone]
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/

[Diez B. Roggisch]

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

[Diez B. Roggisch]

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

[Antoon Pardon]

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

[Rocco Moretti]

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']