I'm wondering why python still has limited lambda support. What's
stopping the developers of python to support more lisp-like lambda function?
--
http://mail.python.org/mailman/listinfo/python-list
Steven Bethard wrote:
Jason Zheng wrote:
I'm wondering why python still has limited lambda support. What's
stopping the developers of python to support more lisp-like lambda
function?
This comes up every few weeks on the list. If you haven't already,
check the archive
This may be a silly question but is possible for os.wait() to lose track
of child processes? I'm running Python 2.4.4 on Linux kernel 2.6.20
(i686), gcc4.1.1, and glibc-2.5.
Here's what happened in my situation. I first created a few child
processes with Popen, then in a while(True) loop wait o
Hate to reply to my own thread, but this is the working program that can
demonstrate what I posted earlier:
import os
from subprocess import Popen
pids = {}
counts = [0,0,0]
for i in xrange(3):
p = Popen('sleep 1', shell=True, cwd='/home',
stdout=file(os.devnull,'w'))
pids[p.pid] = i
greg wrote:
> Jason Zheng wrote:
>> while (True):
>> pid = os.wait()
>> ...
>> if (someCondition):
>> break
> > ...
>
> Are you sure that someCondition() always becomes true
> when the list of pids is empty? If not, you may end
>
Greg,
That explains it! Thanks a lot for your help. I guess this is something
they do to prevent zombie threads?
~Jason
greg wrote:
> Jason Zheng wrote:
>> Hate to reply to my own thread, but this is the working program that
>> can demonstrate what I posted earlier:
>
greg wrote:
> Jason Zheng wrote:
>> Hate to reply to my own thread, but this is the working program that
>> can demonstrate what I posted earlier:
>
> I've figured out what's going on. The Popen class has a
> __del__ method which does a non-blocking wait of
Matthew Woodcraft wrote:
> greg <[EMAIL PROTECTED]> wrote:
>> I've figured out what's going on. The Popen class has a
>> __del__ method which does a non-blocking wait of its own.
>> So you need to keep the Popen instance for each subprocess
>> alive until your wait call has cleaned it up.
>
> I d
Nick Craig-Wood wrote:
> The problem you are having is you are letting Popen do half the job
> and doing the other half yourself.
Except that I never wanted Popen to do any thread management for me to
begin with. Popen class has advertised itself as a replacement for
os.popen, popen2, popen4, an
Hrvoje Niksic wrote:
>> greg wrote:
>
> Actually, it's not that bad. _cleanup only polls the instances that
> are no longer referenced by user code, but still running. If you hang
> on to Popen instances, they won't be added to _active, and __init__
> won't reap them (_active is only populated f
Nick Craig-Wood wrote:
> Sure!
>
> You could get rid of this by sleeping until a SIGCHLD arrived maybe.
Yah, I could also just dump Popen class and use fork(). But then what's
the point of having an abstraction layer any more?
>> This can still be a problem for applications that call wait in a
Hrvoje Niksic wrote:
> Jason Zheng <[EMAIL PROTECTED]> writes:
>
>> Hrvoje Niksic wrote:
>>>> greg wrote:
>>> Actually, it's not that bad. _cleanup only polls the instances that
>>> are no longer referenced by user code, but still running.
Hrvoje Niksic wrote:
> Jason Zheng <[EMAIL PROTECTED]> writes:
>> I'm concerned about portability of my code. It will be run on
>> multiple machines with mixed Python 2.4 and 2.5 environments.
>
> I don't think there is a really clean way to handle this.
13 matches
Mail list logo