' '.join(x for x in l)", 'l = list(map(str,range(10)))').timeit()
3.7431774848480472
Much smaller factor now.
But wait! If we want to test list comprehension against generator
comprehension, we should try a function that just consumes the
iterable.
>>> setup = &qu
Interestingly, I scaled it up to a million list items with more or
less the same results. It's helpful to see that your results are
different. That leads me to suspect that mine are somehow related to
my own environment.
Still I think the key is the overhead in calling next() for each item
in th
On Tue, Jan 19, 2010 at 7:30 AM, Gerald Britton wrote:
[snip]
> mystring = '\n'.join( line for line in lines if depending on line> )
>
Note, this is not a list comprehension, but a generator comprehension.
A list comprehension is used to build, in one sweep, a list and return it.
A generator c
Thanks! Good explanation.
On Tue, Jan 19, 2010 at 10:57 AM, Alf P. Steinbach wrote:
> * Gerald Britton:
>>
>> Yesterday I stumbled across some old code in a project I was working
>> on. It does something like this:
>>
>> mystring = '\n'.join( [ line for line in lines if > depending on line> ] )
* Gerald Britton:
Yesterday I stumbled across some old code in a project I was working
on. It does something like this:
mystring = '\n'.join( [ line for line in lines if ] )
where "lines" is a simple list of strings. I realized that the code
had been written before you could put a list compr
Yesterday I stumbled across some old code in a project I was working
on. It does something like this:
mystring = '\n'.join( [ line for line in lines if ] )
where "lines" is a simple list of strings. I realized that the code
had been written before you could put a list comprehension as an
argum
On Fri, Dec 4, 2009 at 2:11 PM, Joel Davis wrote:
> Yes, sort of like that but Hansen's code is actually exactly what I
> was getting at, not sure why he deleted it:
Huh? I deleted it?
--S
--
http://mail.python.org/mailman/listinfo/python-list
On Dec 4, 3:41 pm, Mensanator wrote:
> On Dec 4, 2:22 pm, Joel Davis wrote:
>
> > Is it possible to run a list comprehension over a certain portion of
> > the list? My goals is to be able to run the comprehension on the
> > innermost elements of the list, but leaving the outermost intact.
>
> Som
On Dec 4, 2:22 pm, Joel Davis wrote:
> Is it possible to run a list comprehension over a certain portion of
> the list? My goals is to be able to run the comprehension on the
> innermost elements of the list, but leaving the outermost intact.
Something like this?
>>> a
[0, 1, 2, 3, 4, 5, 6, 7, 8
>
> Is it possible to run a list comprehension over a certain portion of
> the list? My goals is to be able to run the comprehension on the
> innermost elements of the list, but leaving the outermost intact.
>
Without seeing an example of what your list is, and what you want to turn it
into, its s
Is it possible to run a list comprehension over a certain portion of
the list? My goals is to be able to run the comprehension on the
innermost elements of the list, but leaving the outermost intact.
--
http://mail.python.org/mailman/listinfo/python-list
On Wed, 04 Nov 2009 23:08:54 +1100, Ben Finney wrote:
> Steven D'Aprano writes:
>
>> On Tue, 03 Nov 2009 22:43:45 -0600, Robert Kern wrote:
>> > from numpy import dot
>> >
>> > scalar = dot(vec1, vec2)
>>
>> Why would I want to use an already existing library that is fast, well-
>> written and
d use map, it could use a for-
> loop, a while loop, recursion, or black magic:
>
> scalar = dot_product(vec1, vec2)
Even better.
But now I'm afraid the example is running away from the point.
So to summarize:
1. Extra name bindings and loop keywords aren't always easier to re
Steven D'Aprano writes:
> On Tue, 03 Nov 2009 22:43:45 -0600, Robert Kern wrote:
> > from numpy import dot
> >
> > scalar = dot(vec1, vec2)
>
> Why would I want to use an already existing library that is fast,
> well- written and well-supported, when I can toss together a nasty
> kludge myself?
Steven D'Aprano wrote:
On Tue, 03 Nov 2009 22:43:45 -0600, Robert Kern wrote:
Or use the appropriate libraries:
from numpy import dot
scalar = dot(vec1, vec2)
Why would I want to use an already existing library that is fast, well-
written and well-supported, when I can toss together a nasty
On Tue, 03 Nov 2009 22:43:45 -0600, Robert Kern wrote:
> Steven D'Aprano wrote:
>> On Tue, 03 Nov 2009 10:22:28 -0500, J Kenneth King wrote:
>
>>> Adding in the loop construct and name bindings doesn't enhance my
>>> understanding of what a dot-product is. I don't need to see the loop
>>> constr
Steven D'Aprano wrote:
On Tue, 03 Nov 2009 10:22:28 -0500, J Kenneth King wrote:
Adding in the loop construct and name bindings doesn't enhance my
understanding of what a dot-product is. I don't need to see the loop
construct at all in this case. A dot product is simply the
multiplication of
On Tue, 03 Nov 2009 10:22:28 -0500, J Kenneth King wrote:
> However in this case the procedure by which we derive the value is not
> important or even interesting. It is much more succinct to think of the
> operation as a value and express it accordingly. There's no need to
> clutter the mind wi
en it doesn't solve the stated
> problem: to replace use of ‘map()’ with a list comprehension.
Granted I admit this later in my post. It's not a solution to the OPs
request, but it is the best solution to such a case.
>
>> I understand the OP was asking for it, but list compreh
> Yes, just about any ‘map()’ operation has a corresponding list
> comprehension. (Does anyone know of a counter-example, a ‘map()’
> operation that doesn't have a correspondingly simple list
> comprehension?)
Try turning this into a list comprehension:
vectorsum = lambda *args: map(sum, zip(*a
On Nov 2, 9:01 pm, Ben Finney wrote:
> Anh Hai Trinh writes:
>
> > > Yes, just about any ‘map()’ operation has a corresponding list
> > > comprehension. (Does anyone know of a counter-example, a ‘map()’
> > > operation that doesn't have a correspondingly simple list
> > > comprehension?)
>
> > Tr
On Mon, 02 Nov 2009 20:06:51 -0800, Anh Hai Trinh wrote:
>> Yes, just about any ‘map()’ operation has a corresponding list
>> comprehension. (Does anyone know of a counter-example, a ‘map()’
>> operation that doesn't have a correspondingly simple list
>> comprehension?)
>
> Try turning this into
Anh Hai Trinh writes:
> > Yes, just about any ‘map()’ operation has a corresponding list
> > comprehension. (Does anyone know of a counter-example, a ‘map()’
> > operation that doesn't have a correspondingly simple list
> > comprehension?)
>
> Try turning this into a list comprehension:
>
> vec
Steven D'Aprano writes:
> On Mon, 02 Nov 2009 19:19:41 +1100, Ben Finney wrote:
>
> > "Jon P." writes:
> >
> >> I'd like to do:
> >>
> >> resultlist = operandlist1 + operandlist2
> >
> > That's an unfortunate way of expressing it; it's valid Python syntax
> > that doesn't do what you're descri
> Try turning this into a list comprehension:
>
> vectorsum = lambda *args: map(sum, zip(*args))
>
> vectorsum([1,2], [3,4], [5,6])
> ->[9, 12]
> vectorsum([1,2], [3,4], [5,6], [7,8])
> ->[16, 20]
Nvm, it's actually easy:
vectorsum = lambda *args: [sum(i) for i in zip(*args)]
--
http://ma
> On the other hand, list comps using an if clause can't be written as pure
> maps. You can do this:
>
> [func(x) for x in seq if cond(x)]
>
> filter(cond, map(func, seq))
>
> but the second version may use much more temporary memory if seq is huge
> and cond very rarely true.
You could use ifilte
On Mon, 02 Nov 2009 19:19:41 +1100, Ben Finney wrote:
> "Jon P." writes:
>
>> I'd like to do:
>>
>> resultlist = operandlist1 + operandlist2
>
> That's an unfortunate way of expressing it; it's valid Python syntax
> that doesn't do what you're describing (in this case, it will bind
> ‘resultlis
ge to say it's a solution, when it doesn't solve the stated
> problem: to replace use of ‘map()’ with a list comprehension.
In context, I wasn't giving that as a replacement for map(), but as a
replacement for map-with-a-lambda.
>> I understand the OP was asking for it, b
‘map()’ with a list comprehension.
> I understand the OP was asking for it, but list comprehensions aren't
> the best solution in this case... it would just be line noise.
I disagree; a list comprehension is often clearer than use of ‘map()’
with a lambda form, and I find it to be so in thi
dlist1, operandlist2)
This is the best solution so far.
>
>
>> Is there any reasonable way to do this via a list comprehension ?
>
> [x+y for (x, y) in zip(operandlist1, operandlist2)]
>
> If the lists are huge, you can save some temporary memory by replacing
> zip wit
Ben Finney a écrit :
Bruno Desthuilliers writes:
Ben Finney a écrit :
(Does anyone know of a counter-example, a ‘map()’ operation that
doesn't have a correspondingly simple list comprehension?)
... depends on your definition of "simple". There are things I'd
rather not write as a list compre
Bruno Desthuilliers writes:
> Ben Finney a écrit :
> > (Does anyone know of a counter-example, a ‘map()’ operation that
> > doesn't have a correspondingly simple list comprehension?)
>
> ... depends on your definition of "simple". There are things I'd
> rather not write as a list comprehension...
Steven D'Aprano schrieb:
On Sun, 01 Nov 2009 23:54:16 -0800, Jon P. wrote:
I'd like to do:
resultlist = operandlist1 + operandlist2
where for example
operandlist1=[1,2,3,4,5]
operandlist2=[5,4,3,2,1]
and resultlist will become [6,6,6,6,6]. Using map(), I can do:
map(lambda op1,op2: op1 +
Steven D'Aprano REMOVE.THIS.cybersource.com.au> writes:
> >
> > operandlist1=[1,2,3,4,5]
> > operandlist2=[5,4,3,2,1]
> >
> > and resultlist will become [6,6,6,6,6]. Using map(), I can do:
> >
> > map(lambda op1,op2: op1 + op2, operandlist1, operandlist2)
>
> If the two lists are very large,
Ben Finney a écrit :
(snip)
Yes, just about any ‘map()’ operation has a corresponding list
comprehension.
Right AFAICT, but:
(Does anyone know of a counter-example, a ‘map()’
operation that doesn't have a correspondingly simple list
comprehension?)
... depends on your definition of "simple"
"Jon P." writes:
> I'd like to do:
>
> resultlist = operandlist1 + operandlist2
That's an unfortunate way of expressing it; it's valid Python syntax
that doesn't do what you're describing (in this case, it will bind
‘resultlist’ to a new list that is the *concatenation* of the two
original lists
"Jon P." writes:
> I'd like to do:
>
> resultlist = operandlist1 + operandlist2
>
> where for example
>
> operandlist1=[1,2,3,4,5]
> operandlist2=[5,4,3,2,1]
>
> and resultlist will become [6,6,6,6,6]. Using map(), I
> can do:
>
> map(lambda op1,op2: op1 + op2, operandlist1, operandlist2)
>
> Is
On Sun, 01 Nov 2009 23:54:16 -0800, Jon P. wrote:
> I'd like to do:
>
> resultlist = operandlist1 + operandlist2
>
> where for example
>
> operandlist1=[1,2,3,4,5]
> operandlist2=[5,4,3,2,1]
>
> and resultlist will become [6,6,6,6,6]. Using map(), I can do:
>
> map(lambda op1,op2: op1 + op2,
On Mon, Nov 2, 2009 at 12:54 AM, Jon P. wrote:
> I'd like to do:
>
> resultlist = operandlist1 + operandlist2
>
> where for example
>
> operandlist1=[1,2,3,4,5]
> operandlist2=[5,4,3,2,1]
>
> and resultlist will become [6,6,6,6,6]. Using map(), I
> can do:
>
> map(lambda op1,op2: op1 + op2, opera
Hello,
I'll do the following:
[op1+op2 for op1,op2 in zip(operandlist1, operandlist2)]
Best regards,
Javier
2009/11/2 Jon P. :
> I'd like to do:
>
> resultlist = operandlist1 + operandlist2
>
> where for example
>
> operandlist1=[1,2,3,4,5]
> operandlist2=[5,4,3,2,1]
>
> and resultlist will
I'd like to do:
resultlist = operandlist1 + operandlist2
where for example
operandlist1=[1,2,3,4,5]
operandlist2=[5,4,3,2,1]
and resultlist will become [6,6,6,6,6]. Using map(), I
can do:
map(lambda op1,op2: op1 + op2, operandlist1, operandlist2)
Is there any reasonable way to do this via a
Diez B. Roggisch wrote:
Pat wrote:
I have written chunks of Python code that look this:
new_array = []
for a in array:
if not len( a ):
continue
new_array.append( a )
new_array = [a for a in array if len(a)]
and...
string = ""
for r in r
Steven D'Aprano wrote:
On Mon, 20 Oct 2008 10:20:03 -0400, Pat wrote:
Finally, if someone could point me to a good tutorial or explain list
compressions I would be forever in your debt.
Think of a for-loop:
for x in (1, 2, 3):
x
Creates x=1, then x=2, then x=3. It doesn't do anything wi
#x27;#'))
It seems that a list comprehension could clean up the code, but I seem
to have a mental block on list comprehensions. I've read up a lot on
this subject in my books and on the Internet and for whatever reason,
I'm having problems with this idiom (if that's the cor
On Mon, 20 Oct 2008 10:20:03 -0400, Pat wrote:
> Finally, if someone could point me to a good tutorial or explain list
> compressions I would be forever in your debt.
Think of a for-loop:
for x in (1, 2, 3):
x
Creates x=1, then x=2, then x=3. It doesn't do anything with the x's, but
just c
Pat wrote:
> I have written chunks of Python code that look this:
>
> new_array = []
> for a in array:
> if not len( a ):
> continue
> new_array.append( a )
new_array = [a for a in array if len(a)]
> and...
>
> string = ""
> for r in results:
It seems that a list comprehension could clean up the code, but I seem
to have a mental block on list comprehensions. I've read up a lot on
this subject in my books and on the Internet and for whatever reason,
I'm having problems with this idiom (if that's the correct expression
idiolect wrote:
> On Jun 25, 7:26 pm, Terry Reedy <[EMAIL PROTECTED]> wrote:
>> idiolect wrote:
>> > Hi all - Sorry to plague you with another newbie question from a
>> > lurker. Hopefully, this will be simple.
>>
>> > I have a list full of RGB pixel values read from an image. I want to
>> > tes
On Wed, 25 Jun 2008 16:02:52 -0700, John Machin wrote:
> Here's one approach (requires Python 2.5 or later):
> [(50 if x < 50 else x, 50 if y < 50 else y, 50 if z < 50 else z) for
> (x, y, z) in source]
[(max(x, 50), max(y, 50), max(z, 50)) for (x, y, z) in source]
--
09 F9 11 02 9D 74 E3 5B D8
On Jun 25, 7:26 pm, Terry Reedy <[EMAIL PROTECTED]> wrote:
> idiolect wrote:
> > Hi all - Sorry to plague you with another newbie question from a
> > lurker. Hopefully, this will be simple.
>
> > I have a list full of RGB pixel values read from an image. I want to
> > test each RGB band value per
idiolect wrote:
Hi all - Sorry to plague you with another newbie question from a
lurker. Hopefully, this will be simple.
I have a list full of RGB pixel values read from an image. I want to
test each RGB band value per pixel, and set it to something else if it
meets or falls below a certain
First, I second Matt's comment about using a boring old for loop when
it is the simplest way to express what you want to do. Being Pythonic
is not about using exotic features to scrunch your code down to a cool
one-liner. It is about expressing your intentions in a simple, direct
way. Sometimes
in
> general is rather naive, so I would appreciate any insight anyone can
> offer since I am not sure if I'm even headed down the correct path
> with list comprehensions.
>
"x or y or z < 50" doesn't do what you think it does:
>>> x, y, z = 120, 130, 140
&
in
> general is rather naive, so I would appreciate any insight anyone can
> offer since I am not sure if I'm even headed down the correct path
> with list comprehensions.
>
> Much obliged!
List comprehension is just a tool. If it looks more complicated than
it would if you used
really test and change each value in the tuple individually. My
understanding of the things you can do with lists and python in
general is rather naive, so I would appreciate any insight anyone can
offer since I am not sure if I'm even headed down the correct path
with list comprehensions.
Much o
On May 20, 8:51 pm, "Diez B. Roggisch" <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > John Salerno:
> >> What does everyone think about this?
>
> > The Example 2 builds a list, that is then thrown away. It's just a
> > waste of memory (and time).
>
> No, it doesn't. It uses append becaus
On Tue, May 27, 2008 at 8:08 PM, Gabriel Genellina
<[EMAIL PROTECTED]> wrote:
> En Tue, 27 May 2008 14:43:52 -0300, Ian Kelly <[EMAIL PROTECTED]>
> escribió:
>
>> It sounds like the wasteful list creation is the biggest objection to
>> using a list comprehension. I'm curious what people think of t
On Tue, May 27, 2008 at 7:09 PM, Delaney, Timothy (Tim)
<[EMAIL PROTECTED]> wrote:
> Ian Kelly wrote:
>
>> It sounds like the wasteful list creation is the biggest objection to
>> using a list comprehension. I'm curious what people think of this
>> alternative, which avoids populating the list by
En Tue, 27 May 2008 14:43:52 -0300, Ian Kelly <[EMAIL PROTECTED]>
escribió:
It sounds like the wasteful list creation is the biggest objection to
using a list comprehension. I'm curious what people think of this
alternative, which avoids populating the list by using a generator
expression ins
Ian Kelly wrote:
> It sounds like the wasteful list creation is the biggest objection to
> using a list comprehension. I'm curious what people think of this
> alternative, which avoids populating the list by using a generator
> expression instead (apart from the fact that this is still quadratic,
On May 27, 6:43 pm, "Ian Kelly" <[EMAIL PROTECTED]> wrote:
> On Tue, May 20, 2008 at 11:19 AM, John Salerno <[EMAIL PROTECTED]> wrote:
> > "Diez B. Roggisch" <[EMAIL PROTECTED]> wrote in message
> >news:[EMAIL PROTECTED]
> >> After being corrected about missing the construction of a None-containing
"Ian Kelly" <[EMAIL PROTECTED]> writes:
> On Tue, May 20, 2008 at 11:19 AM, John Salerno <[EMAIL PROTECTED]> wrote:
>> "Diez B. Roggisch" <[EMAIL PROTECTED]> wrote in message
>> news:[EMAIL PROTECTED]
>>> After being corrected about missing the construction of a None-containing
>>> list, one needs
On Tue, May 20, 2008 at 11:19 AM, John Salerno <[EMAIL PROTECTED]> wrote:
> "Diez B. Roggisch" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>> After being corrected about missing the construction of a None-containing
>> list, one needs of course to think about the waste of resource
Simon Forman wrote:
On May 21, 4:36 am, Bruno Desthuilliers wrote:
Simon Forman a écrit :
On May 20, 8:58 am, Paul McGuire <[EMAIL PROTECTED]> wrote:
On May 20, 10:50 am, [EMAIL PROTECTED] wrote:
You don't need all those conditionals. A set differs from a list
precisely in the fact that e
On May 21, 4:36 am, Bruno Desthuilliers wrote:
> Simon Forman a écrit :
>
>
>
> > On May 20, 8:58 am, Paul McGuire <[EMAIL PROTECTED]> wrote:
> >> On May 20, 10:50 am, [EMAIL PROTECTED] wrote:
>
> >>> You don't need all those conditionals. A set differs from a list
> >>> precisely in the fact that
''.join(seen.add(c) or c for c in s if c not in seen)
>From what I can understand...
.join will be a String of unique 'c' values.
'seen.add(c) or c' will always point to the second statement 'c'
because seen.add(c) returns None.
'if c not in seen' will ensure 'c' being added to both the .join a
Simon Forman a écrit :
On May 20, 8:58 am, Paul McGuire <[EMAIL PROTECTED]> wrote:
On May 20, 10:50 am, [EMAIL PROTECTED] wrote:
You don't need all those conditionals. A set differs from a list
precisely in the fact that each element is unique. And since the
function is expecting "s" to be a
On May 20, 8:58 am, Paul McGuire <[EMAIL PROTECTED]> wrote:
> On May 20, 10:50 am, [EMAIL PROTECTED] wrote:
>
>
>
> > You don't need all those conditionals. A set differs from a list
> > precisely in the fact that each element is unique. And since the
> > function is expecting "s" to be an iterable
ake an in-place change is explicit, and it's
being used as everyone expects it to be used. In example 2, however, I began
to think this might be an abuse of list comprehensions, because I'm not
assigning the result to anything (nor am I even using the result in any
way).
What does eve
ake an in-place change is explicit, and it's
being used as everyone expects it to be used. In example 2, however, I began
to think this might be an abuse of list comprehensions, because I'm not
assigning the result to anything (nor am I even using the result in any
way).
What does eve
1, the intention to make an in-place change is explicit,
and it's being used as everyone expects it to be used. In example 2,
however, I began to think this might be an abuse of list
comprehensions, because I'm not assigning the result to anything (nor
am I even using the result in a
On May 20, 11:08 am, Paul Hankin <[EMAIL PROTECTED]> wrote:
> On May 20, 3:58 pm, Paul McGuire <[EMAIL PROTECTED]> wrote:
>
> > def compress(s):
> > seen = set()
> > return ''.join(c for c in s if c not in seen and (seen.add(c) or
> > True))
>
> Slightly nicer is to move the set add out of
-
>
> > In example 1, the intention to make an in-place change is explicit, and it's
> > being used as everyone expects it to be used. In example 2, however, I began
> > to think this might be an abuse of list comprehensions, because I'm not
> > assigning th
"Thomas Bellman" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> "John Salerno" <[EMAIL PROTECTED]> writes:
>
>> "Diez B. Roggisch" <[EMAIL PROTECTED]> wrote in message
>> news:[EMAIL PROTECTED]
>>> the above code is pretty much of a no-no because it has quadratic
>>> runtime
>>> be
On May 20, 12:22 pm, "John Salerno" <[EMAIL PROTECTED]> wrote:
> "Paul McGuire" <[EMAIL PROTECTED]> wrote in message
>
> news:[EMAIL PROTECTED]
> On May 20, 10:50 am, [EMAIL PROTECTED] wrote:
>
> > def compress(s):
> > return list(set(s))
>
> > That does the trick.
>
> Wow, I just *knew* there had
"John Salerno" <[EMAIL PROTECTED]> writes:
> "Diez B. Roggisch" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>> the above code is pretty much of a no-no because it has quadratic runtime
>> behavior.
> What's that mean, exactly?
It means that running time will increase with the s
"John Salerno" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| "Diez B. Roggisch" <[EMAIL PROTECTED]> wrote in message
| news:[EMAIL PROTECTED]
| > the above code is pretty much of a no-no because it has quadratic
runtime
| > behavior.
|
|
| What's that mean, exactly? Are you refer
"Bruno Desthuilliers" <[EMAIL PROTECTED]> wrote in
message news:[EMAIL PROTECTED]
>> def compress(s):
>> new = []
>> [new.append(c) for c in s if c not in new]
>> return ''.join(new)
>
> As far as I'm concerned (and I'm a big fan of list-comps, generator
> expressions etc), this is d
"Paul McGuire" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
On May 20, 10:50 am, [EMAIL PROTECTED] wrote:
> def compress(s):
> return list(set(s))
>
> That does the trick.
Wow, I just *knew* there had to be some built-in function that would make
this problem trivial! :)
Only if o
"Diez B. Roggisch" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> After being corrected about missing the construction of a None-containing
> list, one needs of course to think about the waste of resources, as a
> possible result-list is created in any case.
Yeah, I was already awa
Paul McGuire <[EMAIL PROTECTED]> writes:
> On May 20, 10:17 am, Arnaud Delobelle <[EMAIL PROTECTED]> wrote:
[...]
>>
>> Isn't
>>
>> c not in seen and (seen.add(c) or True)
>>
>> the same as
>>
>> seen.add(c) or c not in seen
>>
>> ?
>>
>> > return ''.join(new)
>>
>> (notice I haven't
"Diez B. Roggisch" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> the above code is pretty much of a no-no because it has quadratic runtime
> behavior.
What's that mean, exactly? Are you referring to both examples, or just the
second one?
--
http://mail.python.org/mailman/list
On May 20, 3:58 pm, Paul McGuire <[EMAIL PROTECTED]> wrote:
> def compress(s):
> seen = set()
> return ''.join(c for c in s if c not in seen and (seen.add(c) or
> True))
Slightly nicer is to move the set add out of the conditional...
def compress(s):
seen = set()
return ''.join(s
On May 20, 10:50 am, [EMAIL PROTECTED] wrote:
>
> You don't need all those conditionals. A set differs from a list
> precisely in the fact that each element is unique. And since the
> function is expecting "s" to be an iterable object, it can be
> constructed even without a for loop:
>
> def compre
t;> [new.append(c) for c in s if c not in new]
> >> return ''.join(new)
> >> --
>
> >> In example 1, the intention to make an in-place change is explicit, and
> >> it's
> >> being used as eve
-
>
> > In example 1, the intention to make an in-place change is explicit, and it's
> > being used as everyone expects it to be used. In example 2, however, I began
> > to think this might be an abuse of list comprehensions, because I'm not
> > assigning th
ample 1, the intention to make an in-place change is explicit, and it's
>> being used as everyone expects it to be used. In example 2, however, I began
>> to think this might be an abuse of list comprehensions, because I'm not
>> assigning the result to anything (nor am I even usi
; new = []
> [new.append(c) for c in s if c not in new]
> return ''.join(new)
> --
>
> In example 1, the intention to make an in-place change is explicit, and it's
> being used as everyone expects it to be used. In example 2, however, I began
&g
Thomas Bellman wrote:
> "Diez B. Roggisch" <[EMAIL PROTECTED]> writes:
>
>> [EMAIL PROTECTED] wrote:
>
>>> The Example 2 builds a list, that is then thrown away. It's just a
>>> waste of memory (and time).
>
>> No, it doesn't. It uses append because it refers to itself in the
>> if-expression.
> That being said, I use that idiom myself. But I don't see anything wrong
> with using a list-comp as loop-abbreviation. because that is it's actual
> purpose. And also it is common in non-functional languages that l-values
> aren't always assigned, if the aren't needed. It's the consequence of
>
if-expression. So the append(c) is needed - and thus the assignment
> possible but essentially useless.
Yes it does. A list comprehension *always* creates a list. In
this case it will be a list of None, since that is what list.append()
returns. See this:
>>> new
Hrvoje Niksic wrote:
> "Diez B. Roggisch" <[EMAIL PROTECTED]> writes:
>
>> [EMAIL PROTECTED] wrote:
>>
>>> John Salerno:
What does everyone think about this?
>>>
>>> The Example 2 builds a list, that is then thrown away. It's just a
>>> waste of memory (and time).
>>
>> No, it doesn't.
>
>
"Diez B. Roggisch" <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] wrote:
>
>> John Salerno:
>>> What does everyone think about this?
>>
>> The Example 2 builds a list, that is then thrown away. It's just a
>> waste of memory (and time).
>
> No, it doesn't.
This line:
[new.append(c) for c i
John Salerno a écrit :
I posted this code last night in response to another thread, and after I
posted it I got to wondering if I had misused the list comprehension.
(snip)
def compress(s):
new = []
[new.append(c) for c in s if c not in new]
return ''.join(new)
As far as I'm con
[EMAIL PROTECTED] wrote:
> John Salerno:
>> What does everyone think about this?
>
> The Example 2 builds a list, that is then thrown away. It's just a
> waste of memory (and time).
No, it doesn't. It uses append because it refers to itself in the
if-expression. So the append(c) is needed - and
John Salerno:
> What does everyone think about this?
The Example 2 builds a list, that is then thrown away. It's just a
waste of memory (and time).
Bye,
bearophile
--
http://mail.python.org/mailman/listinfo/python-list
t; return ''.join(new)
> --
>
> In example 1, the intention to make an in-place change is explicit, and
> it's being used as everyone expects it to be used. In example 2, however,
> I began to think this might be an abuse of list com
explicit, and it's
being used as everyone expects it to be used. In example 2, however, I began
to think this might be an abuse of list comprehensions, because I'm not
assigning the result to anything (nor am I even using the result in any
way).
What does everyone think about this?
>>
>>> Does anybody understand it?
>>>
>>>
>> This isn't _a_ list comprehension, it's *two* list comprehensions. The
>> interpreter computes the value if the inner list comprehension and
>> then duplicates eight references to it (as you
Duncan Booth wrote:
> For the OP, in some languages (e.g. C) 'for' loops typically calculate
> the value of the loop control variable based on some expression
> involving the previous value. Python isn't like that. In Python the data
> used to compute the next value is stored internally: you canno
101 - 200 of 356 matches
Mail list logo
