Python doesn’t play nicely with others | Hacker News Reader

Python doesn’t play nicely with others

leancrew.com

17 pointspavel_lishin11 comments

TL;DR: python's subprocess functionality is weak, particularly when you want to send something into the stdin of your subprocess.

This is not a new observation; it's why envoy exists (as the author acknowledges). If envoy proves successful it ought to make it into the standard library in the future. This is how progress happens.

I also don't get why communicate is "clumsy". I've used it in the past with no problems. Is it just because the syntax is kinda weird or it's not as simple as desired?

Just use communicate()... it's just a 30 lines script. I would understand the complaint if he was doing some work which involved calling a lot of different commands (suggestion: abstract it into your own function, add missing methods to StringIO wrapper), or used pbcopy for many purposes (suggestion: create pbcopy function), or wrote an application which has the main purpose of calling other commands in a nice way (suggestion: use envoy).

But here? Really?

    for f in $* ; do
      (echo ${f/.txt//} ; cat $f) | pbcopy
      osascript < the_copy_script
    done

And let's move to doing some useful things instead. I'm not even sure why he picked on python in this case, since it's the notes application that has issues with interoperability (is it really the easiest way to interact with it? by simulating clicks?)

The very first two lines of the article:

"Today I want to talk about a script that appeared in a post on Mac OS X Hints a couple of days ago. What the script does isn’t of great interest to me, but the technique the programmer used to combine Python and AppleScript is."

That's kind of what I mean. It doesn't matter that .communicate(...) looks bad to the author (it doesn't to me). In any real solution, it's not there. There's a "copy_to_clipboard(contents)" call.

I just get the feeling this was only considered "clumsy" because there is not enough other code to complain about anything else.

> This certainly works, but the communicate method is rather clumsy.

I think this needs expanding. I don't see anything wrong or too clumsy in the communicate method.

The main gripe i've had with it has to do with the subprocess module. It's "semi" unpythonic. There's MORE than one obvious way to do something. Looking at popen, popen2, popen3...that in combination with communicate.

But overall I agree...i don't feel it's too clumsy.

In perl, you can pass a string to a command's stdin.

  use IPC::Cmd qw{run_forked};
  my $applescript = q{display alert "Hello, world!"}
  my $results = run_forked( 'osascript', {child_stdin => $applescript} );

Of course, you're using a package from CPAN. This article mentioned envoy from pypi but refutes it as being "not part of the standard library". The two good solutions he mentions (communicate and envoy) he dismisses for what seem silly or non-reasons to me. (an ill-defined "clumsy" and "not part of the stdlib").

I'm not using a package from CPAN. IPC::Cmd is one of Perl's core modules, just like subprocess is one of Python's standard libraries.

You can find a list of all of the modules distributed with Perl at http://perldoc.perl.org/perlmodlib.html#THE-PERL-MODULE-LIBR...

You can find links to their documentation beginning at http://perldoc.perl.org/index-modules-A.html

subprocess is just a wrapper written in python to the os.* functions. it adds a layer of win32 compatability and a consistant interface at the cost of some features

> I’ve written programs that used os.system or os.popen because, in earlier versions of Python, that was the recommended way to do it

just stick to using os.* - just because the documentation recommends you 'upgrade' doesn't mean it is right.

Reply on news.ycombinator.com