removing list comprehensions in Python 3.0

**Kay Schluehr** · Jul 21 '05, 07:03 AM

Re: removing list comprehensions in Python 3.0

Steven Bethard schrieb:
[color=blue]
> I think the jury's still out on this one:
>
> * Alex Martelli expects list comprehensions to be removed. [1]
> * Robert Kern wants list comprehensions removed. [2]
> * Raymond Hettinger encourages continued use of list comprehensions [3]
> * Jeremy Bowers thinks list comprehensions should stay. [4]
>
> I only searched a few relatively recent threads in c.l.py, so there are
> probably more, but it looks to me like the final decision will have to
> be made by a pronouncement from Guido.[/color]

Well, I want to offer a more radical proposal: why not free squared
braces from the burden of representing lists at all? It should be
sufficient to write
[color=blue][color=green][color=darkred]
>>> list()[/color][/color][/color]
list()

After being free one can use them for other purposes e.g. replacing the
ugly @ decorator character by the lovely [ .. ] notation or other
important features no one never trusted to implement waiting for the
right syntax sugar. More than this round braces together with lists can
be considered as a concession to the LISP programmer who was repelled
from Python by the decision to eliminate functional programming
features.

Kay

**Leif K-Brooks** · Jul 21 '05, 07:03 AM

Re: removing list comprehensions in Python 3.0

Kay Schluehr wrote:[color=blue]
> Well, I want to offer a more radical proposal: why not free squared
> braces from the burden of representing lists at all? It should be
> sufficient to write
>[color=green][color=darkred]
>>>>list()[/color][/color]
>
> list()[/color]

So then what would the expression list('foo') mean? Would it be
equivalent to ['foo'] (if so, how would you convert a string or other
iterable to a list under Py3k?), or would it be equivalent to ['f', 'o',
'o'] as it is in now (and is so, what gives?)?

**Devan L** · Jul 21 '05, 07:03 AM

Re: removing list comprehensions in Python 3.0

List comprehensions are faster than generator comprehensions for
iterating over smaller sequences.

**Steven Bethard** · Jul 21 '05, 07:03 AM

Re: removing list comprehensions in Python 3.0

Kay Schluehr wrote:[color=blue]
> Well, I want to offer a more radical proposal: why not free squared
> braces from the burden of representing lists at all? It should be
> sufficient to write
>[color=green][color=darkred]
>>>>list()[/color][/color]
> list()
>
> After being free one can use them for other purposes e.g. replacing the
> ugly @ decorator character by the lovely [ .. ] notation or other
> important features no one never trusted to implement waiting for the
> right syntax sugar. More than this round braces together with lists can
> be considered as a concession to the LISP programmer who was repelled
> from Python by the decision to eliminate functional programming
> features.[/color]

Heh heh.

So how do I write a list literal then? Or do we only get tuple literals
in Python 3.0. ;)

STeVe

**Steven Bethard** · Jul 21 '05, 07:03 AM

Re: removing list comprehensions in Python 3.0

Devan L wrote:[color=blue]
> List comprehensions are faster than generator comprehensions for
> iterating over smaller sequences.[/color]

Could you give me an example? For the simple one below, the generator
expression was faster:

$ python -m timeit "for x in (i for i in xrange(10)): y = x"
100000 loops, best of 3: 4.75 usec per loop

$ python -m timeit "for x in [i for i in xrange(10)]: y = x"
100000 loops, best of 3: 5.33 usec per loop

And for another one, the results are basically indistinguishab le:

$ python -m timeit "for x in (i for i in 'abcdefg'): y = x"
100000 loops, best of 3: 3.82 usec per loop

$ python -m timeit "for x in [i for i in 'abcdefg']: y = x"
100000 loops, best of 3: 3.87 usec per loop

I vaguely remember that in Python 2.4 conversion to tuples can take
longer because of the tuple extension code:

$ python -m timeit "tuple(i for i in xrange(10000))"
100 loops, best of 3: 2.24 msec per loop

$ python -m timeit "tuple([i for i in xrange(10000)])"
100 loops, best of 3: 1.85 msec per loop

But IIRC, this is supposed to be fixed in Python 2.5.

I found that for some longer sequences, generator expressions were
notably faster:

$ python -m timeit "set(i for i in xrange(10000))"
100 loops, best of 3: 3.77 msec per loop

$ python -m timeit "set([i for i in xrange(10000)])"
100 loops, best of 3: 4.54 msec per loop

Timings that validate your statement would be appreciated. ;)

STeVe

**Dennis Lee Bieber** · Jul 21 '05, 07:03 AM

Re: removing list comprehensions in Python 3.0

On Fri, 08 Jul 2005 16:07:50 -0600, Steven Bethard
<steven.bethard @gmail.com> declaimed the following in comp.lang.pytho n:
[color=blue]
>
> I only searched a few relatively recent threads in c.l.py, so there are
> probably more, but it looks to me like the final decision will have to
> be made by a pronouncement from Guido.
>[/color]
Great... It takes me two releases of Python to get comfortable
with them, and then they are threatened to be removed again...

Might as well submit the language to ISO for standardization --
then I wouldn't be following an erratic target <G>

--[color=blue]
> =============== =============== =============== =============== == <
> wlfraed@ix.netc om.com | Wulfraed Dennis Lee Bieber KD6MOG <
> wulfraed@dm.net | Bestiaria Support Staff <
> =============== =============== =============== =============== == <
> Home Page: <http://www.dm.net/~wulfraed/> <
> Overflow Page: <http://wlfraed.home.ne tcom.com/> <[/color]

**Kay Schluehr** · Jul 21 '05, 07:03 AM

Re: removing list comprehensions in Python 3.0

Leif K-Brooks schrieb:[color=blue]
> Kay Schluehr wrote:[color=green]
> > Well, I want to offer a more radical proposal: why not free squared
> > braces from the burden of representing lists at all? It should be
> > sufficient to write
> >[color=darkred]
> >>>>list()[/color]
> >
> > list()[/color]
>
> So then what would the expression list('foo') mean? Would it be
> equivalent to ['foo'] (if so, how would you convert a string or other
> iterable to a list under Py3k?), or would it be equivalent to ['f', 'o',
> 'o'] as it is in now (and is so, what gives?)?[/color]

Spiltting a string and putting the characters into a list could be done
in method application style:
[color=blue][color=green][color=darkred]
>>> "abc".tolis t()[/color][/color][/color]
list('a','b','c ')

Or equivalent from lists point of view:
[color=blue][color=green][color=darkred]
>>> list.from_str(" abc")[/color][/color][/color]
list("a", "b", "c" )

Kay

**Steven Bethard** · Jul 21 '05, 07:03 AM

Re: removing list comprehensions in Python 3.0

Dennis Lee Bieber wrote:[color=blue]
> On Fri, 08 Jul 2005 16:07:50 -0600, Steven Bethard
> <steven.bethard @gmail.com> declaimed the following in comp.lang.pytho n:
>[color=green]
>>I only searched a few relatively recent threads in c.l.py, so there are
>>probably more, but it looks to me like the final decision will have to
>>be made by a pronouncement from Guido.[/color]
>
> Great... It takes me two releases of Python to get comfortable
> with them, and then they are threatened to be removed again...
>
> Might as well submit the language to ISO for standardization --
> then I wouldn't be following an erratic target <G>[/color]

Two points:

(1) There's no reason to get uncomfortable even if they're removed.
You'd just replace [] with list().

(2) *IMPORTANT* If this happens *at all*, it won't happen until Python
3.0, which is probably at least 5 years away. And the Python 2.X branch
will still be available then, so if you don't like Python 3.0, you don't
have to use it.

STeVe

**Ron Adam** · Jul 21 '05, 07:03 AM

Re: removing list comprehensions in Python 3.0

Kay Schluehr wrote:[color=blue]
>
> Leif K-Brooks schrieb:
>[color=green]
>>Kay Schluehr wrote:
>>[color=darkred]
>>>Well, I want to offer a more radical proposal: why not free squared
>>>braces from the burden of representing lists at all? It should be
>>>sufficient to write
>>>
>>>
>>>>>>list()
>>>
>>>list()[/color]
>>
>>So then what would the expression list('foo') mean? Would it be
>>equivalent to ['foo'] (if so, how would you convert a string or other
>>iterable to a list under Py3k?), or would it be equivalent to ['f', 'o',
>>'o'] as it is in now (and is so, what gives?)?[/color]
>
>
> Spiltting a string and putting the characters into a list could be done
> in method application style:
>
>[color=green][color=darkred]
>>>>"abc".tolis t()[/color][/color]
>
> list('a','b','c ')[/color]

"abc".splitchrs ()

There's already a str.split() to create a list of words,
and a str.splitline() to get a list of lines, so it would group related
methods together.

I don't thin adding sting methods to lists is a good idea.

Cheers,
Ron

**Leif K-Brooks** · Jul 21 '05, 07:03 AM

Re: removing list comprehensions in Python 3.0

Kay Schluehr wrote:[color=blue][color=green][color=darkred]
>>>>list.from_s tr("abc")[/color][/color]
>
> list("a", "b", "c" )[/color]

I assume we'll also have list.from_list, list.from_tuple ,
list.from_genex p, list.from_xrang e, etc.?

**Devan L** · Jul 21 '05, 07:03 AM

Re: removing list comprehensions in Python 3.0

>>> import timeit[color=blue][color=green][color=darkred]
>>> t1 = timeit.Timer('l ist(i for i in xrange(10))')
>>> t1.timeit()[/color][/color][/color]
27.267753024476 576[color=blue][color=green][color=darkred]
>>> t2 = timeit.Timer('[i for i in xrange(10)]')
>>> t2.timeit()[/color][/color][/color]
15.050426800054 197[color=blue][color=green][color=darkred]
>>> t3 = timeit.Timer('l ist(i for i in xrange(100))')
>>> t3.timeit()[/color][/color][/color]
117.61078097914 682[color=blue][color=green][color=darkred]
>>> t4 = timeit.Timer('[i for i in xrange(100)]')
>>> t4.timeit()[/color][/color][/color]
83.502424470149 151

Hrm, okay, so generators are generally faster for iteration, but not
for making lists(for small sequences), so list comprehensions stay.

**Bengt Richter** · Jul 21 '05, 07:03 AM

Re: removing list comprehensions in Python 3.0

On Fri, 08 Jul 2005 22:29:30 -0600, Steven Bethard <steven.bethard @gmail.com> wrote:
[color=blue]
>Dennis Lee Bieber wrote:[color=green]
>> On Fri, 08 Jul 2005 16:07:50 -0600, Steven Bethard
>> <steven.bethard @gmail.com> declaimed the following in comp.lang.pytho n:
>>[color=darkred]
>>>I only searched a few relatively recent threads in c.l.py, so there are
>>>probably more, but it looks to me like the final decision will have to
>>>be made by a pronouncement from Guido.[/color]
>>
>> Great... It takes me two releases of Python to get comfortable
>> with them, and then they are threatened to be removed again...
>>
>> Might as well submit the language to ISO for standardization --
>> then I wouldn't be following an erratic target <G>[/color]
>
>Two points:
>
>(1) There's no reason to get uncomfortable even if they're removed.
>You'd just replace [] with list().[/color]

So list(1, 2, 3) will be the same as [1, 2, 3] ??

Right now,[color=blue][color=green][color=darkred]
>>> list(1,2,3)[/color][/color][/color]
Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: list() takes at most 1 argument (3 given)

have fun ;-)
[color=blue]
>
>(2) *IMPORTANT* If this happens *at all*, it won't happen until Python
>3.0, which is probably at least 5 years away. And the Python 2.X branch
>will still be available then, so if you don't like Python 3.0, you don't
>have to use it.
>
>STeVe[/color]

Regards,
Bengt Richter

**Ron Adam** · Jul 21 '05, 07:03 AM

Re: removing list comprehensions in Python 3.0

Leif K-Brooks wrote:[color=blue]
> Kay Schluehr wrote:
>[color=green][color=darkred]
>>>>>list.from_ str("abc")[/color]
>>
>>list("a", "b", "c" )[/color]
>
>
>
> I assume we'll also have list.from_list, list.from_tuple ,
> list.from_genex p, list.from_xrang e, etc.?[/color]

List from list isn't needed, nor list from tuple. That's what the * is
for. And for that matter neither is the str.splitchar() either.

class mylist(list):
def __init__(self,* args):
self[:]=args[:]

mylist(*[1,2,3]) -> [1,2,3]

mylist(*(1,2,3) ) -> [1,2,3]

mylist(*"abc") -> ['a','b','c']

mylist(1,2,3) -> [1,2,3]

mylist([1],[2]) -> [[1],[2]]

mylist('hello', 'world') -> ['hello','world']

Works for me. ;-)

I always thought list([1,2,3]) -> [1,2,3] was kind of silly.

Cheers,
Ron

**Kay Schluehr** · Jul 21 '05, 07:03 AM

Re: removing list comprehensions in Python 3.0

Leif K-Brooks schrieb:[color=blue]
> Kay Schluehr wrote:[color=green][color=darkred]
> >>>>list.from_s tr("abc")[/color]
> >
> > list("a", "b", "c" )[/color]
>
>
> I assume we'll also have list.from_list, list.from_tuple ,
> list.from_genex p, list.from_xrang e, etc.?[/color]

One might unify all those factory functions into a single
list.from_iter that dispatches to the right constructor that still
lives under the hood. More conceptually: there is some abstract iter
base class providing a from_iter method which may be overwritten in
concrete subclasses like tuple, str or list.

I would further suggest a lazy iterator used to evaluate objects when
they get accessed the first time:
[color=blue][color=green][color=darkred]
>>> l = lazy( math.exp(100) , 27 )[/color][/color][/color]
<lazy-iterator object at 0x4945f0>[color=blue][color=green][color=darkred]
>>> l[1][/color][/color][/color]
27

The first element won't ever be evaluated if it does not get accessed
explicitely. This is some very special kind of partial
evaluation/specialization.

Kay

removing list comprehensions in Python 3.0

removing list comprehensions in Python 3.0

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment