> I've written a couple of apps that required
> running a command and grabbing the output,
> and I've found the existing interfaces problematic for this.
You're not the only one who has found this. Have a look at PEP 324.
> Therefore I bit the bullet and wrote my own,
> with as simple an interface as I thought possible:
> Perhaps this could be included in commands.py for e.g.?
As it stands, this looks like it is Unix-only, which would probably
be an issue for a standard library function.
This e-mail and the documents attached are confidential and intended
solely for the addressee; it may also be privileged. If you receive this
e-mail in error, please notify the sender immediately and destroy it.
As its integrity cannot be secured on the Internet, the Atos Origin group
liability cannot be triggered for the message content. Although the
sender endeavours to maintain a computer virus-free network, the sender
does not warrant that this transmission is virus-free and will not be
liable for any damages resulting from any virus transmitted.
I've written a couple of apps that required
running a command and grabbing the output,
and I've found the existing interfaces problematic for this.
I think the proliferation of functions and classes
in the popen2 module illustrates the problem
Now if I want to read both stdout and stderr
seperately then it's awkward to say the least
to implement that without deadlocking using
the popen2 module. Also the multiplexing of
stdout and stderr in popen4 and commands.getoutput
is not usually what one requires IMHO.
There are external solutions like the getCommandOutput recipe:
which has problems that I've commented on there.
There are also very complex solutions like "subproc" from
Ken Manheimer and "task" from Rob Hooft
Therefore I bit the bullet and wrote my own,
with as simple an interface as I thought possible:
Perhaps this could be included in commands.py for e.g.?
Any comments appreciated.
p.s. sorry about the previous case of trigger finger
Why do we have modules logging(2.3) and warnings(2.1)? Does 'logging'
deprecate 'warnings' in any way?
I know this question doesn't belong in this list. I appreciate any
clarifications anyway. Thanks in advance.
Gustavo J. A. M. Carneiro
The universe is always one step beyond logic
Any objections to my adding a NOP instruction to support additional code
generation improvements in Python/compile.c?
One possible improvement is replacing [UNARY_NOT JUMP_IF_FALSE addr]
with [NOP JUMP_IF_TRUE addr].
I apologize if this has already been discussed or implemented in CVS but
I am not up to date on python development.
With the release of GCC 3.4 and the continuing development of GCC 3.5,
lvalue casts in C are being deprecated. Fortunately GCC 3.4 only spits
out a warning for them. Unfortunately, us crazies using 3.5 will
encounter an unfriendly error with the lvalue casts generated by pyrexc.
Any information on this issue would be appreciated...thanks!
PS: please CC me as I'm not subscribed
One feature that I'd find nice in itertools is access to "universal
newlines" behavior. This would make it much easier to extend zipfile
and other compression-related code to provide pseudo-files that iterate
To try out a simple Python equivalent, look at:
If people think such code would be useful in itertools, I'd be happy to
add it as a patch. If not, I'll provide it as a Cookbook recipe or
-- Scott David Daniels
#- > I maintain that when comparing a long with a float
#- > where the exponent is larger than the precision, that the
#- > float should be treated as if it were EXACTLY EQUAL TO
#- > <coefficient>*2^<exponent>, instead of trying to treat it as
#- > some sort of a range. Similarly, if we implemented a Rational
#- > type, I would suggest that instances of float (or of Facundo's
#- > Decimal) where <exponent> is LESS than the digits of
#- > <coefficient> should be treated as if they were EXACTLY EQUAL
#- > TO the corresponding fraction-over-a-power-of-two.
Don't get to understand this. Could you send please an example of Decimal to