Edvard Majakari wrote:
> Steven Bethard <[EMAIL PROTECTED]> writes:
>
>>$ python -m timeit "for x in (i for i in xrange(10)): y = x"
>>10 loops, best of 3: 4.75 usec per loop
>
> Yowza! One of the features I really liked in Perl has shored Python island
> somewhere in the 2.4'ies, it seems[1]
Steven Bethard <[EMAIL PROTECTED]> writes:
> $ python -m timeit "for x in (i for i in xrange(10)): y = x"
> 10 loops, best of 3: 4.75 usec per loop
Yowza! One of the features I really liked in Perl has shored Python island
somewhere in the 2.4'ies, it seems[1]. Thanks for the tip!
PS. In cas
Steven Bethard wrote:
> py> def ge(items):
> ... return (item for item in items if item)
> ...
Bengt Richter wrote:
> >>> dis.dis(ge)
>2 0 LOAD_CONST 1 ( expression> at 02EE4FA0, file "", line 2>)
>3 MAKE_FUNCTION0
>6 LOA
> 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()
>
>From a visual comprehenison point of view, I would assert that the square form
>[] is much easier on the
On Sat, 09 Jul 2005 22:32:22 -0600, Steven Bethard <[EMAIL PROTECTED]> wrote:
>Raymond Hettinger wrote:
>> [Steven Bethard]
>>
>>>I would hope that in Python 3.0 list comprehensions and generator
>>>expressions would be able to share a large amount of implementation, and
>>>thus that the speed di
Raymond Hettinger wrote:
> [Steven Bethard]
>
>>I would hope that in Python 3.0 list comprehensions and generator
>>expressions would be able to share a large amount of implementation, and
>>thus that the speed differences would be much smaller. But maybe not...
>
> Looking under the hood, you w
[Raymond Hettinger]
> > It is darned inconvenient to get an iterator when you really
> > need a list, when you want to slice the result, when you want to see a
> > few elements through repr(), and when you need to loop over the
> > contents more than once.
[George Sakkis]
> Similar arguments can b
[Steven Bethard]
> I would hope that in Python 3.0 list comprehensions and generator
> expressions would be able to share a large amount of implementation, and
> thus that the speed differences would be much smaller. But maybe not...
Looking under the hood, you would see that the implementations
Raymond Hettinger wrote:
> The root of this discussion has been the observation that a list
> comprehension can be expressed in terms of list() and a generator
> expression.
As George Sakkis already noted, the root of the discussion was actually
the rejection of the dict comprehensions PEP.
> Ho
Devan L wrote:
import timeit
t1 = timeit.Timer('list(i for i in xrange(10))')
t1.timeit()
>
> 27.267753024476576
>
t2 = timeit.Timer('[i for i in xrange(10)]')
t2.timeit()
>
> 15.050426800054197
>
t3 = timeit.Timer('list(i for i in xrange(100))')
t3.timeit()
>
> 117
"George Sakkis" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> It's funny how one of the
> arguments for removing lambda -- you can do the same by defining a
> named function -- does not apply for list comprehensions.
Which is a point a number of people have made many times,
with
"Raymond Hettinger" <[EMAIL PROTECTED]> wrote:
> In all probability, both list comprehensions and generator expressions
> will be around in perpetuity. List comps have been a very successful
> language feature.
>
> The root of this discussion has been the observation that a list
> comprehension c
"Raymond Hettinger" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> In all probability, both list comprehensions and generator expressions
> will be around in perpetuity. List comps have been a very successful
> language feature.
>
> The root of this discussion has been the observat
On Sat, 09 Jul 2005 10:16:17 -0400, Peter Hansen <[EMAIL PROTECTED]> wrote:
>Bengt Richter wrote:
>> On Fri, 08 Jul 2005 22:29:30 -0600, Steven Bethard <[EMAIL PROTECTED]> wrote:
>>>(1) There's no reason to get uncomfortable even if they're removed.
>>>You'd just replace [] with list().
>>
>> So
In all probability, both list comprehensions and generator expressions
will be around in perpetuity. List comps have been a very successful
language feature.
The root of this discussion has been the observation that a list
comprehension can be expressed in terms of list() and a generator
expressi
Bengt Richter wrote:
> On Fri, 08 Jul 2005 22:29:30 -0600, Steven Bethard <[EMAIL PROTECTED]> wrote:
>>(1) There's no reason to get uncomfortable even if they're removed.
>>You'd just replace [] with list().
>
> So list(1, 2, 3) will be the same as [1, 2, 3] ??
No, the discussion is about list c
Leif K-Brooks schrieb:
> Kay Schluehr wrote:
> list.from_str("abc")
> >
> > list("a", "b", "c" )
>
>
> I assume we'll also have list.from_list, list.from_tuple,
> list.from_genexp, list.from_xrange, etc.?
One might unify all those factory functions into a single
list.from_iter that dispatches
Leif K-Brooks wrote:
> Kay Schluehr wrote:
>
>list.from_str("abc")
>>
>>list("a", "b", "c" )
>
>
>
> I assume we'll also have list.from_list, list.from_tuple,
> list.from_genexp, list.from_xrange, etc.?
List from list isn't needed, nor list from tuple. That's what the * is
for. And for t
On Fri, 08 Jul 2005 22:29:30 -0600, Steven Bethard <[EMAIL PROTECTED]> wrote:
>Dennis Lee Bieber wrote:
>> On Fri, 08 Jul 2005 16:07:50 -0600, Steven Bethard
>> <[EMAIL PROTECTED]> declaimed the following in comp.lang.python:
>>
>>>I only searched a few relatively recent threads in c.l.py, so the
>>> import timeit
>>> t1 = timeit.Timer('list(i for i in xrange(10))')
>>> t1.timeit()
27.267753024476576
>>> t2 = timeit.Timer('[i for i in xrange(10)]')
>>> t2.timeit()
15.050426800054197
>>> t3 = timeit.Timer('list(i for i in xrange(100))')
>>> t3.timeit()
117.61078097914682
>>> t4 = timeit.Time
Kay Schluehr wrote:
list.from_str("abc")
>
> list("a", "b", "c" )
I assume we'll also have list.from_list, list.from_tuple,
list.from_genexp, list.from_xrange, etc.?
--
http://mail.python.org/mailman/listinfo/python-list
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 t
Dennis Lee Bieber wrote:
> On Fri, 08 Jul 2005 16:07:50 -0600, Steven Bethard
> <[EMAIL PROTECTED]> 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
>>
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
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"
10 loops, best of 3
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
List comprehensions are faster than generator comprehensions for
iterating over smaller sequences.
--
http://mail.python.org/mailman/listinfo/python-list
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
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 comp
29 matches
Mail list logo
