Fixing the Python subprocess interface
amoffat.github.com
Fixing the Python subprocess interface
1–10 of 65 posts
Re: Fixing the Python subprocess interface
#2Neat but way too magical for my taste. The code to figure out what to do in the case of 'from .. import *' is particularly ugly.
Perhaps the commands should accessible from an object you import. That's slightly more typing but more explicit and would not require ugly magic. E.g.
from pbs import sh
print sh.ifconfig('eth')
Re: Fixing the Python subprocess interface
#3That's pretty brilliant, well done.
Re: Fixing the Python subprocess interface
#4Neat but way too magical for my taste. The code to figure out what to do in the case of 'from .. import *' is particularly ugly. Perhaps the commands should accessible from an object you import. That's slightly more typing but more explicit and would not require ugly magic. E.g. from pbs import sh print sh.ifconfig('eth') If it's not clear, the 'sh' object could override __getattr__ or __getattribute__ and wrap comma…
Anything that encourages a from ... import * usage is evil irrespective of its implementation.
Re: Fixing the Python subprocess interface
#5Neat but way too magical for my taste. The code to figure out what to do in the case of 'from .. import *' is particularly ugly. Perhaps the commands should accessible from an object you import. That's slightly more typing but more explicit and would not require ugly magic. E.g. from pbs import sh print sh.ifconfig('eth') If it's not clear, the 'sh' object could override __getattr__ or __getattribute__ and wrap comma…
Anything that encourages a from ... import * usage is evil irrespective of its implementation.
Why?
Re: Fixing the Python subprocess interface
#6Why not use pipes for piping? e.g. print du("*", "-sb") | sort("-rn")
Re: Fixing the Python subprocess interface
#7Neat but way too magical for my taste. The code to figure out what to do in the case of 'from .. import *' is particularly ugly. Perhaps the commands should accessible from an object you import. That's slightly more typing but more explicit and would not require ugly magic. E.g. from pbs import sh print sh.ifconfig('eth') If it's not clear, the 'sh' object could override __getattr__ or __getattribute__ and wrap comma…
To avoid any magic you could use:
ifconfig = pbs.Command("/path/to/ifconfig")Re: Fixing the Python subprocess interface
#8It's odd that the import mechanism is abused here to make objects "out of thin air". The fact that "from pbs import ffmpeg" works only if ffmpeg is actually on the path is somewhat surprising.
I think the more comfortable (and Pythonic?) way to do this would be to explicitly create these command objects:
>>> import pbs
>>> ffmpeg = pbs.Command('ffmpeg') # or '/usr/bin/ffmpeg', perhaps
>>> result = ffmpeg(...)
Re: Fixing the Python subprocess interface
#9Very impressive, but the use of globals and the dynamic lookup mechanism are a little scary. Looking at the source there seems to be some magic involved like hacking the interpreter.
I'd feel more comfortable if it only exported one variable.