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

61–65 of 65 posts

Re: Fixing the Python subprocess interface

#61

Post by rat87 »

scott_s wrote: post #47
ulope wrote: post #43

Earlier quoted context omitted.

As long as the package you need doesn't include a C extension (which most don't) you can just ship it with your code (license permitting ofc.) - just add the path to the libary to sys.path. It's not a very clean solution but can be a real life saver when you have to work on "broken" systems.

Sorry, I wasn't clear. This is a system I log into every day, and I don't want to maintain my own install of Python and related packages on it. It's too much overhead. I'd rather just use the default Python, even though it's old.

For simple libs I just dump the py file/folder in the same folder as the script and import.

Re: Fixing the Python subprocess interface

#63

Post by gbog »

ulope wrote: post #13
petsos wrote: post #5

Earlier quoted context omitted.

Why?

Because it leads to namespace pollution and hard-to-track-down bugs. It's especially bad in this case where adding an executable in the system can suddenly shadow any built-in name (e.g. imagine someone adds a "print" or "sys" executable).

Refactoring is also made much harder with import * if you have cascading modules. I have a pylint hook forbidding these before committing to our hg repo

Re: Fixing the Python subprocess interface

#64

Post by gbog »

jmtulloss wrote: post #29

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.

I have the feeling you misunderstood the problem with magic. In fact, having a function calling shell command is ok. The problem is to know, from reading the code, where it comes from. In python there is this idea of transparency, the determinism, which is with it feels enlightening, like in the docs cartoon. Anything obscuring that is said to be unpythonic.

Re: Fixing the Python subprocess interface

#65

Post by fmoralesc »

daenz wrote: post #57
trun wrote: post #55

Reminds me of something I saw not too long ago... https://github.com/JulienPalard/Pipe It would be really cool (though admittedly less Pythonic) to combine the infix notation provided by the Pipe library to allow more shell-like function chaining. Instead of this... print wc(ls("/etc", "-1"), "-l") You would have this... print ls("/etc", "-1") | wc("-l")

There's a few ideas floating around here https://github.com/amoffat/pbs/issues/6 on how to implement it, but nothing looks really feasible. If you have any insights, I welcome them :)

I wrote some code for that a while ago: https://gist.github.com/1300342
Post reply on HN