Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   Python (http://www.velocityreviews.com/forums/f43-python.html)
-   -   list(...) and list comprehensions (WAS: Arithmetic sequences in Python) (http://www.velocityreviews.com/forums/t353555-list-and-list-comprehensions-was-arithmetic-sequences-in-python.html)

 Steven Bethard 01-18-2006 06:24 PM

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

Tom Anderson <twic@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)

[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 01-18-2006 07:46 PM

Re: list(...) and list comprehensions (WAS: Arithmetic sequencesin 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)

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 01-18-2006 07:55 PM

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-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 01-18-2006 07:59 PM

Re: list(...) and list comprehensions (WAS: Arithmetic sequencesin 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-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/

 Diez B. Roggisch 01-18-2006 08:09 PM

Re: list(...) and list comprehensions (WAS: Arithmetic sequencesin 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 *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 01-18-2006 08:21 PM

Re: list(...) and list comprehensions (WAS: Arithmetic sequencesin 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 - 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 01-20-2006 11:33 AM

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

Op 2006-01-18, Diez B. Roggisch schreef <deets@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 01-20-2006 04:13 PM

Re: list(...) and list comprehensions (WAS: Arithmetic sequencesin 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):

return list(args)

>>> print list_from_scalars(1,2,3)

[1, 2, 3]
>>> print list_from_scalars('a')

['a']
>>>

 All times are GMT. The time now is 10:21 PM.