I just had a thought. os.system will yield the exit
> status, but the stdout, stderr messages automatically get
> passed on to sys.stdout. I think I could temporarily
> redirect sys.stdout long enough to catch that information
> behind the scenes. Is there a reason not to pursue this
> route?
I think it may be ill-advised for a library to be mucking around with
sys.stdout, since the calling application may be doing the same.
JDH
John Hunter wrote:
"Darren" == Darren Dale <dd55@...143...> writes:
> I just had a thought. os.system will yield the exit
> status, but the stdout, stderr messages automatically get
> passed on to sys.stdout. I think I could temporarily
> redirect sys.stdout long enough to catch that information
> behind the scenes. Is there a reason not to pursue this
> route?I think it may be ill-advised for a library to be mucking around with
sys.stdout, since the calling application may be doing the same.
Sorry I missed this thread while working on fixes to _subprocess.c in
MPL svn. (Only required on win32.)
First, I didn't realize there was an extension module involved, either.
This is because it's a platform-dependent (win32) requirement, and I
don't frequently use Windows. I agree this makes it a harder choice to
include.
Second, I believe the page pointed to by Darren is out-of-date: the most
recent update to subprocess.py is from Feb 21, 2005, while in Python svn
the most recent update is September 23. I've updated our svn repository
to the most recent subprocess and hopefully made a few robustness
improvements.
Third, if we (Darren) determines subprocess isn't needed, after all, we
can rip it out again. (My feelings won't be hurt.) I'm just concerned
that he's going to re-implement what they've already done. Wouldn't it
just be easier to see what aspects of it are win32-dependent tread
carefully? After all, the whole purpose of the module is exactly so that
all this stuff is done by subprocess, and if there are win32-dependent
issues remaining, it's most likely that there's a good reason (like its
simply not possible on win32).
I've been banging my head against this all day. There are other solutions that
will help usetex get by, but subprocess does exactly what we need. So Andrew,
if you were able to get the subprocess extension code to work properly in the
mpl tree, I'll owe you a doughnut.
(That is the official form of currency on this list, isn't it?)
On Friday 17 March 2006 14:51, Andrew Straw wrote:
John Hunter wrote:
>>>>>>"Darren" == Darren Dale <dd55@...143...> writes:
>
> > I just had a thought. os.system will yield the exit
> > status, but the stdout, stderr messages automatically get
> > passed on to sys.stdout. I think I could temporarily
> > redirect sys.stdout long enough to catch that information
> > behind the scenes. Is there a reason not to pursue this
> > route?
>
>I think it may be ill-advised for a library to be mucking around with
>sys.stdout, since the calling application may be doing the same.Sorry I missed this thread while working on fixes to _subprocess.c in
MPL svn. (Only required on win32.)First, I didn't realize there was an extension module involved, either.
This is because it's a platform-dependent (win32) requirement, and I
don't frequently use Windows. I agree this makes it a harder choice to
include.Second, I believe the page pointed to by Darren is out-of-date: the most
recent update to subprocess.py is from Feb 21, 2005, while in Python svn
the most recent update is September 23. I've updated our svn repository
to the most recent subprocess and hopefully made a few robustness
improvements.Third, if we (Darren) determines subprocess isn't needed, after all, we
can rip it out again. (My feelings won't be hurt.) I'm just concerned
that he's going to re-implement what they've already done. Wouldn't it
just be easier to see what aspects of it are win32-dependent tread
carefully? After all, the whole purpose of the module is exactly so that
all this stuff is done by subprocess, and if there are win32-dependent
issues remaining, it's most likely that there's a good reason (like its
simply not possible on win32).