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
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 <
[email protected]> 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
In article <[EMAIL PROTECTED]>,
"Terry Reedy" <[EMAIL PROTECTED]> wrote:
> "Mel Wilson" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> > Point of information, would this be the interpreter putting
> > the result of its last calculation in _ ?
>
> Yes, [ ... ]
No, actually. It'
"Mel Wilson" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Point of information, would this be the interpreter putting
> the result of its last calculation in _ ?
Yes, in interactive mode (but not in batch mode) it binds the valid name
'_' to the result of statement expressions.
[EMAIL PROTECTED] wrote:
> Lonnie> List comprehensions appear to store their temporary result in a
> Lonnie> variable named "_[1]" (or presumably "_[2]", "_[3]" etc for
> Lonnie> nested comprehensions)
>
> Known issue. Fixed in generator comprehensions. Dunno about plans to fix
> it
Ben Cartwright schrieb:
> [EMAIL PROTECTED] wrote:
>> Lonnie> List comprehensions appear to store their temporary result in a
>> Lonnie> variable named "_[1]" (or presumably "_[2]", "_[3]" etc for
>> Lonnie> nested comprehensions)
>>
>> Known issue. Fixed in generator comprehensions. Dunn
[EMAIL PROTECTED] wrote:
> Lonnie> List comprehensions appear to store their temporary result in a
> Lonnie> variable named "_[1]" (or presumably "_[2]", "_[3]" etc for
> Lonnie> nested comprehensions)
>
> Known issue. Fixed in generator comprehensions. Dunno about plans to fix
> it in li
Lonnie> List comprehensions appear to store their temporary result in a
Lonnie> variable named "_[1]" (or presumably "_[2]", "_[3]" etc for
Lonnie> nested comprehensions)
Known issue. Fixed in generator comprehensions. Dunno about plans to fix
it in list comprehensions. I believe a
20 matches
Mail list logo
