Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fixing the Python subprocess interface

amoffat.github.com

Post reply on HN
Print view View original

21–30 of 65 posts

Re: Fixing the Python subprocess interface

#21

Post by SoftwareMaven »

samps wrote: post #8

It'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(...) [Edit:…

Except that changes what it is trying to accomplish. The goal (as I read it) is to make shell scripting more palatable in python. Needing to continually differentiate between "this is python" and "this is system" gets old very fast.

In your example, what pbs is doing is no different than a bash shell script reporting a "command not found". It isn't what I would want if I were writing a complex piece of software interacting with ffmpeg, but for a simple script to process a bunch of files in a directory, I like it.

I've tended to shy away from using Python for shell scripting because subprocess is so ugly (even its out-of-favor, crippled relative os.system is nasty), and pbs looks like it does a really great job at addressing that.

Re: Fixing the Python subprocess interface

#22

Post by samps »

SoftwareMaven wrote: post #21
samps wrote: post #8

It'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(...) [Edit:…

Except that changes what it is trying to accomplish. The goal (as I read it) is to make shell scripting more palatable in python. Needing to continually differentiate between "this is python" and "this is system" gets old very fast. In your example, what pbs is doing is no different than a bash shell script reporting a "command not found". It isn't what I would want if I were writing a complex piece of software inter…

Agreed. As a way to write one-off scripts that one would otherwise use bash for, this seems like a nice trick.

Re: Fixing the Python subprocess interface

#23

Post by tswicegood »

tswicegood wrote: post #17

FWIW, re-replaying the stack trace to figure out what was imported and re-implementing it is a horrible idea. There are much better ways to do this type of import voodoo, specifically the import hooks that Python ships with. Here's an example of their use inside a small side project of mine: https://github.com/tswicegood/maxixe/blob/master/maxixe/__in... All that said, this is horribly un-Pythonic. A much better rout…

Just to clarify. I applaud this type of development for people trying to learn various parts of Python like playing with the stack, but the idea of this being used in the wild scares me a bit.

Re: Fixing the Python subprocess interface

#27

Post by viraptor »

tantalor wrote: post #16
VMG wrote: post #10

Earlier quoted context omitted.

pollution of the global name space

Irrelevant for shell-style scripts because they are entry points, not included from other modules. --And its not a "global" name space, its just the namespace of your script.--

It's a global namespace in your script. That's what it's called, I believe and it's available via globals().

Re: Fixing the Python subprocess interface

#29

Post by jmtulloss »

So many people saying this is "too much magic". Whatever, I'm into it. The idea of commands being functions that can just pass their output to other functions is intuitive, and passing arguments as, well, arguments is as well.

It might not be pythonic, it might be a crime against Guido and everything he represents, but it's pretty awesome.

Re: Fixing the Python subprocess interface

#30

Post by veyron »

petsos wrote: post #6

Why not use pipes for piping? e.g. print du("*", "-sb") | sort("-rn")

If you interpret the return value as a file (output file handle) then the function application method makes sense. This really falters when trying to use tee, but then again using pipes doesnt help either.
Post reply on HN