Vincent Vande Vyvre writes:
> final = [(x, y+1) for x, y in zip(e, e)]
final = [(x, x+1) for x in e]
--
Piet van Oostrum
WWW: http://pietvanoostrum.com/
PGP key: [8DAE142BE17999C4]
--
https://mail.python.org/mailman/listinfo/python-list
Roel Schroeven writes:
> Lele Gaifax schreef op 6/04/2017 20:07:
>> Piet van Oostrum writes:
>>
>>> It is a poor man's 'let'. It would be nice if python had a real 'let'
>>> construction. Or for example:
>>>
>>> [(tmp, tmp + 1) for x in data with tmp = expensive_calculation(x)]
>>>
>>> Alas!
>>
>
Lele Gaifax schreef op 6/04/2017 20:07:
Piet van Oostrum writes:
It is a poor man's 'let'. It would be nice if python had a real 'let'
construction. Or for example:
[(tmp, tmp + 1) for x in data with tmp = expensive_calculation(x)]
Alas!
It would be nice indeed!
Or even
[(tmp, tmp + 1)
On 2017-04-06 14:56, Vincent Vande Vyvre wrote:
> With two passes
>
> e = [expensive_calculation(x) for x in data]
> final = [(x, y+1) for x, y in zip(e, e)]
Using a generator it can be done in one pass:
final = [
(value, tmp, tmp+1)
for value, tmp
in (
(x, expensive_calculation(x
Piet van Oostrum writes:
> It is a poor man's 'let'. It would be nice if python had a real 'let'
> construction. Or for example:
>
> [(tmp, tmp + 1) for x in data with tmp = expensive_calculation(x)]
>
> Alas!
It would be nice indeed!
Or even
[(tmp, tmp + 1) for x in data
with expensive_c
Vincent Vande Vyvre writes:
> Le 06/04/17 à 14:25, Piet van Oostrum a écrit :
>> Steven D'Aprano writes:
>>
>>> Suppose you have an expensive calculation that gets used two or more
>>> times in a loop. The obvious way to avoid calculating it twice in an
>>> ordinary loop is with a temporary varia
Le 06/04/17 à 14:25, Piet van Oostrum a écrit :
Steven D'Aprano writes:
Suppose you have an expensive calculation that gets used two or more times in a
loop. The obvious way to avoid calculating it twice in an ordinary loop is with
a temporary variable:
result = []
for x in data:
tmp = e
Steven D'Aprano writes:
> Suppose you have an expensive calculation that gets used two or more times in
> a
> loop. The obvious way to avoid calculating it twice in an ordinary loop is
> with
> a temporary variable:
>
> result = []
> for x in data:
> tmp = expensive_calculation(x)
> r
On Sunday, April 2, 2017 at 1:08:17 AM UTC+1, Robert L. wrote:
> I don't believe in western morality, i.e. don't kill civilians or children
> The only way to fight a moral war is the Jewish way: Destroy their holy sites.
> Kill men, women, and children (and cattle). --- Rabbi Manis Friedman
>
On 1/8/2017, Steven D'Aprano wrote:
> Suppose you have an expensive calculation that gets used two or
> more times in a loop. The obvious way to avoid calculating it
> twice in an ordinary loop is with a temporary variable:
>
> result = []
> for x in data:
> tmp = expensive_calculation(x)
>
On Sun, Apr 2, 2017 at 11:53 AM, Steve D'Aprano
wrote:
> Robert, I've asked you once to stop posting anti-Semitic signatures in your
> posts. You've now posted four times, and each one has included racist
> material in the signature.
>
> You are welcome to participate here if you discuss Python, o
Robert, I've asked you once to stop posting anti-Semitic signatures in your
posts. You've now posted four times, and each one has included racist
material in the signature.
You are welcome to participate here if you discuss Python, or even to
discuss general programming techniques, but if you cont
On Tuesday 10 January 2017 00:12, Antoon Pardon wrote:
> Op 09-01-17 om 04:53 schreef Steven D'Aprano:
>> Suppose you have an expensive calculation that gets used two or more times
>> in a loop. The obvious way to avoid calculating it twice in an ordinary loop
>> is with a temporary variable:
[...
On Monday, 9 January 2017 03:53:37 UTC, Steven D'Aprano wrote:
> Suppose you have an expensive calculation that gets used two or more times
> in a loop.
[...]
> [(tmp, tmp + 1) for x in data for tmp in [expensive_calculation(x)]]
>
> I can't decide whether that's an awesome trick or a horrible
On 01/09/2017 04:53 AM, Steven D'Aprano wrote:
Suppose you have an expensive calculation that gets used two or more times in a
loop. The obvious way to avoid calculating it twice in an ordinary loop is with
a temporary variable:
result = []
for x in data:
tmp = expensive_calculation(x)
On 09.01.17 12:46, Paul Rubin wrote:
Serhiy Storchaka writes:
gen = (expensive_calculation(x) for x in data)
result = [(tmp, tmp + 1) for tmp in gen]
result = [(tmp, tmp+1) for tmp in map(expensive_calculation, data)]
Yes, of course, but only in the case of one-argument function
expensive_
Ben Bacarisse writes:
> [(lambda tmp: (tmp, tmp+1))(expensive_calculation(x)) for x in data]
Nice. The Haskell "let" expression is implemented as syntax sugar for
that, I believe.
--
https://mail.python.org/mailman/listinfo/python-list
On 2017-01-09 13:16, Paul Rubin wrote:
> Tim Chase writes:
> >> result = [(tmp, tmp+1) for tmp in map(expensive_calculation,
> >> data)]
> >
> > As charmingly expressive as map() is, the wildly different
> > behavior in py3 (it's a generator that evaluates lazily) vs py2
> > (it consumes the entir
Steven D'Aprano writes:
> Suppose you have an expensive calculation that gets used two or more times in
> a
> loop. The obvious way to avoid calculating it twice in an ordinary loop is
> with
> a temporary variable:
>
> result = []
> for x in data:
> tmp = expensive_calculation(x)
> r
Tim Chase writes:
>> result = [(tmp, tmp+1) for tmp in map(expensive_calculation, data)]
>
> As charmingly expressive as map() is, the wildly different behavior in
> py3 (it's a generator that evaluates lazily) vs py2 (it consumes the
> entire iterable in one go) leads me to avoid it in general,
Am 09.01.17 um 04:53 schrieb Steven D'Aprano:
Or do you? ... no, you don't!
[(tmp, tmp + 1) for x in data for tmp in [expensive_calculation(x)]]
I can't decide whether that's an awesome trick or a horrible hack...
I think this is quite clear, and a useful feature, only that Python
makes it u
On Sunday, January 8, 2017 at 7:53:37 PM UTC-8, Steven D'Aprano wrote:
> Suppose you have an expensive calculation that gets used two or more times in
> a
> loop. The obvious way to avoid calculating it twice in an ordinary loop is
> with
> a temporary variable:
>
> result = []
> for x in data
On 2017-01-09 04:59, Rustom Mody wrote:
> What happens when the expensive is on an inner generator?
> Something like:
>
> [expensive₂(y) for x in data for y in foo(x)]
>
> [The ₂ representing the 2 or more occurrences in Steven's eg]
Well, if I understand your question correctly, the goal would
Op 09-01-17 om 04:53 schreef Steven D'Aprano:
> Suppose you have an expensive calculation that gets used two or more times in
> a
> loop. The obvious way to avoid calculating it twice in an ordinary loop is
> with
> a temporary variable:
>
> result = []
> for x in data:
> tmp = expensive_ca
nsive_calculation, data)]
>
> As charmingly expressive as map() is, the wildly different behavior in
> py3 (it's a generator that evaluates lazily) vs py2 (it consumes the
> entire iterable in one go) leads me to avoid it in general,
> especially when Python gives me list-comp
ior in
py3 (it's a generator that evaluates lazily) vs py2 (it consumes the
entire iterable in one go) leads me to avoid it in general,
especially when Python gives me list-comprehensions and generators
that can do what I intend explicitly. E.g., passing in
itertools.count() as an iterable to map
Serhiy Storchaka writes:
> gen = (expensive_calculation(x) for x in data)
> result = [(tmp, tmp + 1) for tmp in gen]
result = [(tmp, tmp+1) for tmp in map(expensive_calculation, data)]
--
https://mail.python.org/mailman/listinfo/python-list
Steven D'Aprano writes:
> [(expensive_calculation(x), expensive_calculation(x) + 1) for x in data]
def memoize(f):
cache = {}
def m(x):
if x in cache:
return cache[x]
a = f(x)
cache[x] = a
r
On 09.01.17 05:53, Steven D'Aprano wrote:
Suppose you have an expensive calculation that gets used two or more times in a
loop. The obvious way to avoid calculating it twice in an ordinary loop is with
a temporary variable:
result = []
for x in data:
tmp = expensive_calculation(x)
result
On Monday, January 9, 2017 at 10:19:31 AM UTC+5:30, Steven D'Aprano wrote:
> On Monday 09 January 2017 15:09, Chris Angelico wrote:
>
> > On Mon, Jan 9, 2017 at 2:53 PM, Steven D'Aprano wrote:
> >> [(tmp, tmp + 1) for x in data for tmp in [expensive_calculation(x)]]
> >>
> >>
> >> I can't decide w
On Mon, Jan 9, 2017 at 3:49 PM, Steven D'Aprano
wrote:
> Helper functions are good. Helper functions that are only used
> *once* are a code smell. *LOTS* of helper functions that are only used once
> are
> a sign that something is horrible, and it might just be your language...
Agreed, but with
On Monday 09 January 2017 15:09, Chris Angelico wrote:
> On Mon, Jan 9, 2017 at 2:53 PM, Steven D'Aprano
> wrote:
>> [(tmp, tmp + 1) for x in data for tmp in [expensive_calculation(x)]]
>>
>>
>> I can't decide whether that's an awesome trick or a horrible hack...
>
> A horrible hack on par with
On Mon, Jan 9, 2017 at 2:53 PM, Steven D'Aprano
wrote:
> [(tmp, tmp + 1) for x in data for tmp in [expensive_calculation(x)]]
>
>
> I can't decide whether that's an awesome trick or a horrible hack...
A horrible hack on par with abusing a recursive function's arguments
for private variables. Much
Suppose you have an expensive calculation that gets used two or more times in a
loop. The obvious way to avoid calculating it twice in an ordinary loop is with
a temporary variable:
result = []
for x in data:
tmp = expensive_calculation(x)
result.append((tmp, tmp+1))
But what if you ar
arsh...@gmail.com wrote:
> I am having some understandable behaviour from one of my function name
> week_graph_data() which call two functions those return a big tuple of
> tuples, But in function week_graph_data() line no. 30 does not
> work(returns no result in graph or error).
>
> I have check
I am having some understandable behaviour from one of my function name
week_graph_data() which call two functions those return a big tuple of tuples,
But in function week_graph_data() line no. 30 does not work(returns no result
in graph or error).
I have check both functions are called in week
Hi Arsh, and welcome!
On Wed, 3 Feb 2016 12:30 am, arsh...@gmail.com wrote:
> I am having some understandable behaviour from one of my function name
> week_graph_data() which call two functions those return a big tuple of
> tuples, But in function week_graph_data() line no. 30 does not
> work(ret
On Wed, Sep 23, 2015 at 12:12 PM, James Harris wrote:
> A list comprehension has various components. Anyone know when each of the
> elements is evaluated? In the form
>
> [v0 for v0 in expr0 if expr1]
>
> If v0 appears in expr0 or expr1 the evaluation order matters.
>
> I think of the above as be
A list comprehension has various components. Anyone know when each of
the elements is evaluated? In the form
[v0 for v0 in expr0 if expr1]
If v0 appears in expr0 or expr1 the evaluation order matters.
I think of the above as being a rewrite of
results = []
for v0 in expr0:
if expr1:
On 12/22/2014 12:10 PM, Chris Angelico wrote:
On Tue, Dec 23, 2014 at 2:18 AM, Steven D'Aprano
wrote:
Chris Angelico wrote:
On Mon, Dec 22, 2014 at 8:21 PM, Steven D'Aprano
wrote:
If the called function has side-effects, a list comp is not a good
solution.
Hmm. I'm not so sure about that.
On Monday, December 22, 2014 8:37:50 PM UTC+5:30, Chris Angelico wrote:
> On Tue, Dec 23, 2014 at 1:58 AM, Rustom Mody wrote:
> > If you consider side-effecting comprehensions as kosher,
> > then a next conclusion is naturally going to be that
> > multiple generator comprehensions are confusing and
On Tue, Dec 23, 2014 at 2:18 AM, Steven D'Aprano
wrote:
> Chris Angelico wrote:
>
>> On Mon, Dec 22, 2014 at 8:21 PM, Steven D'Aprano
>> wrote:
>>> If the called function has side-effects, a list comp is not a good
>>> solution.
>>
>> Hmm. I'm not so sure about that. Side effects are fine in a li
On 22/12/2014 05:42, Ganesh Pal wrote:
Hi ,
(a) I was trying to reduce the below piece of code using List
comprehension ? Any suggestion please let me know
for opt in options:
opt['result'] = Queue.Queue()
tmp_thread = pause.Thread(opt)
threads.append(tmp
Chris Angelico wrote:
> On Mon, Dec 22, 2014 at 8:21 PM, Steven D'Aprano
> wrote:
>> If the called function has side-effects, a list comp is not a good
>> solution.
>
> Hmm. I'm not so sure about that. Side effects are fine in a list comp,
> as long as you're making use of the return values. For
On Mon, Dec 22, 2014 at 2:21 AM, Steven D'Aprano <
steve+comp.lang.pyt...@pearwood.info> wrote:
> > (b) * Is there anything that I need to consider while using list
> > comprehension with threads ?*
>
> That depends on what you mean by "using list comprehension with threads".
>
> If you mean "use
On Tue, Dec 23, 2014 at 1:58 AM, Rustom Mody wrote:
> If you consider side-effecting comprehensions as kosher,
> then a next conclusion is naturally going to be that
> multiple generator comprehensions are confusing and therefore
> not kosher -- a very unfortunate conclusion IMHO.
Why does that f
On Monday, December 22, 2014 6:52:12 PM UTC+5:30, Chris Angelico wrote:
> On Tue, Dec 23, 2014 at 12:07 AM, Roy Smith wrote:
> > def init_thread(opt):
> >opt['result'] = Queue.Queue()
> >thread = pause.Thread(opt)
> >thread.start()
> >return thread
> >
> > threads = [init_thread(opt
On Tue, Dec 23, 2014 at 12:07 AM, Roy Smith wrote:
> def init_thread(opt):
>opt['result'] = Queue.Queue()
>thread = pause.Thread(opt)
>thread.start()
>return thread
>
> threads = [init_thread(opt) for opt in options]
If this is, indeed, just initializing the threads, then this mig
In article ,
Chris Angelico wrote:
> On Mon, Dec 22, 2014 at 4:42 PM, Ganesh Pal wrote:
> > (a) I was trying to reduce the below piece of code using List comprehension
> > ? Any suggestion please let me know
> >
> >
> > for opt in options:
> > opt['result'] = Queue.Queue()
> >
On Mon, Dec 22, 2014 at 8:21 PM, Steven D'Aprano
wrote:
> If the called function has side-effects, a list comp is not a good solution.
Hmm. I'm not so sure about that. Side effects are fine in a list comp,
as long as you're making use of the return values. For instance, if
you have a function tha
Ganesh Pal wrote:
> Hi ,
>
>
> (a) I was trying to reduce the below piece of code using List
> comprehension ? Any suggestion please let me know
>
>
> for opt in options:
> opt['result'] = Queue.Queue()
> tmp_thread = pause.Thread(opt)
> threads.append(tmp_t
On Mon, Dec 22, 2014 at 4:42 PM, Ganesh Pal wrote:
> (a) I was trying to reduce the below piece of code using List comprehension
> ? Any suggestion please let me know
>
>
> for opt in options:
> opt['result'] = Queue.Queue()
> tmp_thread = pause.Thread(opt)
> th
Hi ,
(a) I was trying to reduce the below piece of code using List
comprehension ? Any suggestion please let me know
for opt in options:
opt['result'] = Queue.Queue()
tmp_thread = pause.Thread(opt)
threads.append(tmp_thread)
tmp_thread.start()
(b)
On 04/27/12 07:23, Chris Angelico wrote:
On Fri, Apr 27, 2012 at 10:17 PM, John O'Hagan wrote:
results = [x = expensive_call(i) for i in iterable if condition(x)]
Nest it:
results = [x for x in (expensive_call(i) for i in iterable) if condition(x)]
While it's what I do in cases like this,
On Fri, Apr 27, 2012 at 10:17 PM, John O'Hagan wrote:
> results = [x = expensive_call(i) for i in iterable if condition(x)]
Nest it:
results = [x for x in (expensive_call(i) for i in iterable) if condition(x)]
ChrisA
--
http://mail.python.org/mailman/listinfo/python-list
On Fri, 27 Apr 2012 19:57:31 +1000
Chris Angelico wrote:
> On Fri, Apr 27, 2012 at 7:49 PM, Miles Rout wrote:
> > We have if inside list comprehensions? I didn't know that, could you provide
> > an example?
>
> You mean like:
>
> [x*2+1 for x in range(
On Fri, Apr 27, 2012 at 8:37 PM, Tim Wintle wrote:
> Or like:
>
print [ 0 if b%2==1 else 1 for b in range(10)]
> [1, 0, 1, 0, 1, 0, 1, 0, 1, 0]
That's nothing to do with the list comp, that's just the expression-if
syntax that you can use anywhere.
ChrisA
--
http://mail.python.org/mailman/
On Fri, 2012-04-27 at 19:57 +1000, Chris Angelico wrote:
> On Fri, Apr 27, 2012 at 7:49 PM, Miles Rout wrote:
> > We have if inside list comprehensions? I didn't know that, could you provide
> > an example?
>
> You mean like:
>
> [x*2+1 for x in range(10) if x%3]
ldn't need 'if'
inside of list comprehensions either.
Kiuhnm
We have if inside list comprehensions? I didn't know that, could you
provide an example?
elems = [4, 1, 9, 6, 3, 8, 3, 9, 2]
small_elems = [x for x in elems if x < 5]
print str(small_elems) # 4, 1, 3, 3,
On Fri, Apr 27, 2012 at 7:49 PM, Miles Rout wrote:
> We have if inside list comprehensions? I didn't know that, could you provide
> an example?
You mean like:
[x*2+1 for x in range(10) if x%3]
?
ChrisA
--
http://mail.python.org/mailman/listinfo/python-list
On 27/04/2012 5:57 a.m., Kiuhnm wrote:
On 4/26/2012 19:48, Paul Rubin wrote:
Roy Smith writes:
x = [a for a in iterable while a]
from itertools import takewhile
x = takewhile(bool, a)
I see that as a 'temporary' solution, otherwise we wouldn't need 'if'
insi
t;
> I see that as a 'temporary' solution, otherwise we wouldn't need 'if' inside
> of list comprehensions either.
The "if" clause is much more commonly used than "while" would be. I
don't have any objections to the suggestion from a techn
On 4/26/2012 19:48, Paul Rubin wrote:
Roy Smith writes:
x = [a for a in iterable while a]
from itertools import takewhile
x = takewhile(bool, a)
I see that as a 'temporary' solution, otherwise we wouldn't need 'if'
inside of list comprehensions either.
Kiuhnm
Roy Smith writes:
> x = [a for a in iterable while a]
from itertools import takewhile
x = takewhile(bool, a)
--
http://mail.python.org/mailman/listinfo/python-list
On 4/26/2012 19:02, Roy Smith wrote:
I'm not seriously suggesting this as a language addition, just an interesting
idea to simplify some code I'm writing now:
x = [a for a in iterable while a]
which equates to:
x = []
for a in iterable:
if not a:
break
x.append(a)
It does
On 26/04/2012 18:02, Roy Smith wrote:
I'm not seriously suggesting this as a language addition, just an interesting
idea to simplify some code I'm writing now:
x = [a for a in iterable while a]
which equates to:
x = []
for a in iterable:
if not a:
break
x.append(a)
It does
On Thu, Apr 26, 2012 at 11:02 AM, Roy Smith wrote:
> I'm not seriously suggesting this as a language addition, just an interesting
> idea to simplify some code I'm writing now:
>
> x = [a for a in iterable while a]
>
> which equates to:
>
> x = []
> for a in iterable:
> if not a:
> brea
On Thu, Apr 26, 2012 at 10:02 AM, Roy Smith wrote:
>
> I'm not seriously suggesting this as a language addition, just an interesting
> idea to simplify some code I'm writing now:
>
> x = [a for a in iterable while a]
>
> which equates to:
>
> x = []
> for a in iterable:
> if not a:
> br
On Thu, Apr 26, 2012 at 10:02 AM, Roy Smith wrote:
> I'm not seriously suggesting this as a language addition, just an interesting
> idea to simplify some code I'm writing now:
>
> x = [a for a in iterable while a]
>
> which equates to:
>
> x = []
> for a in iterable:
> if not a:
> brea
I'm not seriously suggesting this as a language addition, just an interesting
idea to simplify some code I'm writing now:
x = [a for a in iterable while a]
which equates to:
x = []
for a in iterable:
if not a:
break
x.append(a)
It does has a few things going for it. It doesn't
Steven D'Aprano wrote:
On Mon, 05 Dec 2011 19:57:15 +0100, Jean-Michel Pichavant wrote:
The proper way to propagate information with exceptions is using the
exception itself:
try:
songs = [Song(_id) for _id in song_ids]
except Song.DoesNotExist, exc:
print exc
I'm not entire
On Tuesday, December 6, 2011 2:42:35 PM UTC+8, Rainer Grimm wrote:
> Hello,
>
> > try:
> > songs = [Song(id) for id in song_ids]
> > except Song.DoesNotExist:
> > print "unknown song id (%d)" % id
> that's is a bad programming style. So it will be forbidden with python 3. T
Hello,
> try:
> songs = [Song(id) for id in song_ids]
> except Song.DoesNotExist:
> print "unknown song id (%d)" % id
that's is a bad programming style. So it will be forbidden with python 3. The
reason is that list comprehension is a construct from the functional world.
On Tue, Dec 6, 2011 at 9:57 AM, Roy Smith wrote:
> I may be in the minority here, but it doesn't bother me much that my use of
> 'id' shadows a built-in. Especially in small scopes like this, I use
> whatever variable names make the the code easiest to read and don't worry
> about shadowing bu
On 12/5/2011 5:36 PM, Roy Smith wrote:
Well, in my defense, I did ask a pretty narrow question, "Is id
guaranteed to be in scope in the print statement?".
Yes for 2.x, guaranteed no for 3.x.
If you had simply asked "Is the loop variable of a list comprehension
guaranteed to be in scope after
Sigh. I attempted to reduce this to a minimal example to focus the discussion
on the question of list comprehension variable scope. Instead I seem to have
gotten people off on other tangents. I suppose I should post more of the real
code...
song_ids = request.POST.getlist('song_id')
On Mon, 05 Dec 2011 19:57:15 +0100, Jean-Michel Pichavant wrote:
> The proper way to propagate information with exceptions is using the
> exception itself:
>
> try:
> songs = [Song(_id) for _id in song_ids]
> except Song.DoesNotExist, exc:
> print exc
I'm not entirely sure that this is
Well, in my defense, I did ask a pretty narrow question, "Is id guaranteed to
be in scope in the print statement?". While I will admit that not knowing
whether I could alter the exception, or whether id masked a builtin or not does
complexify answering some questions, those are questions I didn
On 12/5/2011 2:15 PM, Roy Smith wrote:
Hmmm, the use of id was just a simplification for the sake of
posting. The real code is a bit more complicated and used a
different variable name, but that's a good point.
As far as storing the value in the exception, unfortunately,
DoesNotExist is not my
Hmmm, the use of id was just a simplification for the sake of posting. The
real code is a bit more complicated and used a different variable name, but
that's a good point.
As far as storing the value in the exception, unfortunately, DoesNotExist is
not my exception; it comes from deep within d
on.org/tutorial/datastructures.html#list-comprehensions, are
mute on this point.
For python 2, id will always be defined *as you meant it*. But you're
doing something wrong : overiding the 'id' builtin function.
With python 3 you will probably print the 'id' builtin function
And for Python 3 also?
>
> The current docs,
> http://docs.python.org/tutorial/datastructures.html#list-comprehensions,
> are mute on this point.
If you are using a generator expression id will already be out of scope in
Python 2. In Python 3 list comprehensions have been changed to work the
Roy Smith writes:
> Consider the following django snippet. Song(id) raises DoesNotExist
> if the id is unknown.
>
> try:
> songs = [Song(id) for id in song_ids]
> except Song.DoesNotExist:
> print "unknown song id (%d)" % id
>
> Is id guaranteed to be in scope in the pri
ure, is that still true? And for Python 3 also?
>
In Python2, id will always be in scope, unless the first iteration fails
(aka, an empty iterable, or a custom iterable which raises an exception
before yielding a result).
I believe in Python3, the scoping of list comprehensions was changed to
ma
one thread
(http://mail.python.org/pipermail/python-bugs-list/2006-April/033235.html)
which says yes, but hints that it might not always be in the future. Now that
we're in the future, is that still true? And for Python 3 also?
The current docs,
http://docs.python.org/tutorial/datastruc
On Tue, 15 Feb 2011 18:55:50 -0500, Gerald Britton wrote:
> So, what's the feeling out there? Go with map and the operators or
> stick with the list comps?
Stick to whatever feels and reads better at the time.
Unless you have profiled your code, and determined that the map or list
comp was the
Generally, I prefer map() over list comprehensions since they are more
succinct and run faster for non-trivial examples. However, I've been
considering another use case related to functions in the operator
module. Here are some examples:
[x.method() for x in data]
[x[0] for x in data]
[x
Steven D'Aprano wrote:
A million items is not a lot of data. Depending on the size of each
object, that might be as little as 4 MB of data:
L = ['' for _ in xrange(10**6)]
sys.getsizeof(L)
4348732
Note that this sys.getsizeof() is only saying the size of the list, not
the size
* Steven D'Aprano:
On Wed, 20 Jan 2010 05:25:22 +0100, Alf P. Steinbach wrote:
* Steven D'Aprano:
On Tue, 19 Jan 2010 16:20:42 -0500, Gerald Britton wrote:
That's surprising. I wouldn't implement it that way at all. I'd use a
dynamically-expanding buffer as I suggested. That way you get a
Steven D'Aprano, 20.01.2010 07:12:
> On Wed, 20 Jan 2010 05:25:22 +0100, Alf P. Steinbach wrote:
>> That is a good argument for not doing the expanding buffer thing.
>> But such buffers may be generally present anyway, resulting from
>> optimization of "+".
>
> As near as I can determine, the CPyt
On Wed, 20 Jan 2010 05:25:22 +0100, Alf P. Steinbach wrote:
> * Steven D'Aprano:
>> On Tue, 19 Jan 2010 16:20:42 -0500, Gerald Britton wrote:
>>
>>> That's surprising. I wouldn't implement it that way at all. I'd use a
>>> dynamically-expanding buffer as I suggested. That way you get a
>>> sing
* Steven D'Aprano:
On Tue, 19 Jan 2010 16:20:42 -0500, Gerald Britton wrote:
That's surprising. I wouldn't implement it that way at all. I'd use a
dynamically-expanding buffer as I suggested. That way you get a single
pass and don't have to calculate anything before you begin. In the best
ca
On Tue, 19 Jan 2010 16:20:42 -0500, Gerald Britton wrote:
> That's surprising. I wouldn't implement it that way at all. I'd use a
> dynamically-expanding buffer as I suggested. That way you get a single
> pass and don't have to calculate anything before you begin. In the best
> case, you'd use
On Tue, 19 Jan 2010 11:26:43 -0500, Gerald Britton wrote:
> Interestingly, I scaled it up to a million list items with more or less
> the same results.
A million items is not a lot of data. Depending on the size of each
object, that might be as little as 4 MB of data:
>>> L = ['' for _ in xrang
Gerald Britton writes:
> That's surprising. I wouldn't implement it that way at all. I'd use a
> dynamically-expanding buffer as I suggested. That way you get a
> single pass and don't have to calculate anything before you begin. In
> the best case, you'd use half the memory (the result just f
[Wolfram Hinderer]
> Yes, list building from a generator expression *is* expensive. And
> join has to do it, because it has to iterate twice over the iterable
> passed in: once for calculating the memory needed for the joined
> string, and once more to actually do the join (this is implementation
>
That's surprising. I wouldn't implement it that way at all. I'd use a
dynamically-expanding buffer as I suggested. That way you get a
single pass and don't have to calculate anything before you begin. In
the best case, you'd use half the memory (the result just fits in the
buffer after its last
On 19 Jan., 21:06, Gerald Britton wrote:
> [snip]
>
>
>
> > Yes, list building from a generator expression *is* expensive. And
> > join has to do it, because it has to iterate twice over the iterable
> > passed in: once for calculating the memory needed for the joined
> > string, and once more to
Gerald Britton writes:
> [snip]
>
>>
>> Yes, list building from a generator expression *is* expensive. And
>> join has to do it, because it has to iterate twice over the iterable
>> passed in: once for calculating the memory needed for the joined
>> string, and once more to actually do the join (
[snip]
>
> Yes, list building from a generator expression *is* expensive. And
> join has to do it, because it has to iterate twice over the iterable
> passed in: once for calculating the memory needed for the joined
> string, and once more to actually do the join (this is implementation
> dependen
1 - 100 of 356 matches
Mail list logo
