«

George Sakkis wrote:
> "Steven Bethard" <> wrote:
>> Dict comprehensions were recently rejected:
>> http://www.python.org/peps/pep-0274.html
>> The reason, of course, is that dict comprehensions don't gain you
>> much at all over the dict() constructor plus a generator expression,
>> e.g.:
>> dict((i, chr(65+i)) for i in range(4))
>
> Sure, but the same holds for list comprehensions: list(i*i for i in
> xrange(10)). The difference is historic I guess; list comprehensions
> preceded generator expressions and so they cannot be removed, at least
> not before 3.0. I wonder if they will/should be in the language when
> the constraint of backwards compatibility is lifted. IMO they should
> not (TIOOWTDI, uniformity among builtin data structures, not
> overwhelmingly more useful than set or dict comprehensions), but
> there's a long way till that day.

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.

[1]http://groups-beta.google.com/group/comp.lang.python/msg/f5613c00cb8c9539
[2]http://groups-beta.google.com/group/comp.lang.python/msg/b2cf0cd72d53fbe5
[3]http://groups-beta.google.com/group/comp.lang.python/msg/781dfab03701dd18
[4]http://groups-beta.google.com/group/comp.lang.python/msg/771a47d9eb24c863

Steven Bethard schrieb:

> 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.

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()

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

Kay Schluehr wrote:
> 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()

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?)?

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

Kay Schluehr wrote:
> 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()
>
> 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.

Heh heh.

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

STeVe

Devan L wrote:
> List comprehensions are faster than generator comprehensions for
> iterating over smaller sequences.

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 indistinguishable:

$ 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

On Fri, 08 Jul 2005 16:07:50 -0600, Steven Bethard
<> declaimed the following in comp.lang.python:

>
> 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.
>
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>

--
> ================================================== ============ <
> | Wulfraed Dennis Lee Bieber KD6MOG <
> | Bestiaria Support Staff <
> ================================================== ============ <
> Home Page: <http://www.dm.net/~wulfraed/> <
> Overflow Page: <http://wlfraed.home.netcom.com/> <

Leif K-Brooks schrieb:
> Kay Schluehr wrote:
> > 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()
>
> 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?)?

Spiltting a string and putting the characters into a list could be done
in method application style:

>>> "abc".tolist()
list('a','b','c')

Or equivalent from lists point of view:

>>> list.from_str("abc")
list("a", "b", "c" )

Kay

Dennis Lee Bieber wrote:
> On Fri, 08 Jul 2005 16:07:50 -0600, Steven Bethard
> <> declaimed the following in comp.lang.python:
>
>>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.
>
> 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>

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

Kay Schluehr wrote:
>
> Leif K-Brooks schrieb:
>
>>Kay Schluehr wrote:
>>
>>>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()
>>
>>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?)?
>
>
> Spiltting a string and putting the characters into a list could be done
> in method application style:
>
>
>>>>"abc".tolist()
>
> list('a','b','c')

"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