PEP idea: On Windows, subprocess should implicitly support .bat and .cmd scripts by using FindExecutable from win32 API

[Chris Angelico]

On Thu, May 7, 2015 at 11:44 PM, Marko Rauhamaa <marko at pacujo.net> wrote:
> Chris Angelico <rosuav at gmail.com>:
>
>>> A software system is defined through its interfaces.
>>
>> And the most important interface is with a human.
>
> I barely ever program anything for the human interface.
>
>> If you want to write single-platform code, go for it; but if you want
>> to write cross-platform code, the best way is to let someone else take
>> care of the differences, abstracting them away into a nice tidy thing
>> that we call a high-level language.
>
> You suggested most software should be platform-agnostic. Now you are
> qualifying the statement.

I'm qualifying it because it's impossible to write 100%
platform-agnostic code without restricting yourself far too much; but
that doesn't mean that it isn't a worthwhile aim.

> But still, I challenge the notion that you could write a web site, game
> or application that feels natural on the XBox, iPhone, Windows PC and
> LXDE at the same time without significant amounts of
> platform-conditioned parts.

Hmm, you're picking up some very different things there. When a human
picks up an iPhone, s/he expects to use it with a touch-based
interface; I don't know what the normal UI for an Xbox is, but Xbox
users would; and the most normal interface for LXDE would be a
mouse+keyboard. The ideal UI for each of them will differ. This is the
same as coding your application differently if you expect a blind
person to use it, or if you want to make it possible to use your
program in a theatre without disturbing the audience, or any other UI
constraint you wish to concoct. That's nothing to do with platform. If
you write a program for Ubuntu, it might go onto a tablet or a
desktop, and the ideal UI for those is (in my opinion, though not
apparently in Unity's) different.

But if you design your program to be used with the same fundamental
human interface - say, a mouse and a keyboard - then you should be
able to do that the same way on many platforms. I've seen libraries
that let you build an ncurses-like interface or a full GUI window,
using exactly the same application code. It's not difficult.

>> I don't need forking, file descriptors, or process IDs, to describe
>> how a person uses my code. Those are *implementation details*.
>
> Even if I programmed for the human and the UI experience were
> more-or-less identical between platforms, the system interfaces can be
> conceptually quite different. Heroic attempts have been made to overcome
> those differences with generic APIs. However, Python should stay out of
> that crusade.
>
> Whole programming cultures, idioms and "right ways" differ between
> platforms. What's the right way to write a service (daemon)? That's
> probably completely different between Windows and Linux. Linux itself is
> undergoing a biggish transformation there: an exemplary daemon of last
> year will likely be deprecated within a few years.

And that's where a library function can be really awesome. What's the
right way to daemonize? "import daemonize; daemonize.daemonize()"
seems good to me. Maybe there's platform-specific code in the
*implementation* of that, but in your application, no. That's the job
of a layer underneath you.

Incidentally, the way I'm seeing things shift these days is mainly
toward *not* daemonizing your services at all. That makes life a lot
easier; instead of writing special code to put yourself in the
background, you just write your code to the standard basic "glass
teletype" model, and then add a little config file that makes it run
in the background. But a Python module could provide a generic
"install as service" function, which will create a systemd config
file, or a Windows service whatever-it-is, or the equivalent on a Mac,
or an Upstart job file, or whatever it detects. Same difference. A
library takes care of all of that.

In Python, we have the 'subprocess' module. Due to Windows
limitations, you have to restrict yourself to having an importable
main file if you want perfect cross-platform compatibility, but that
doesn't affect how your code runs on Linux or Mac OS. What's the best
way to farm work off to a bunch of processes and have them communicate
their results back? You use the subprocess module, and then it doesn't
matter whether they use Unix sockets, named pipes, physical files on
the disk, or miniature nuclear explosions, they'll communicate back
just fine. And when someone develops a new platform that uses nuclear
fusion instead of fission for interprocess communication, Python's
standard library gets enhanced, and your code instantly works - you
don't have to specifically handle the new case.

That's Python's job. Abstracting away all those differences so you
don't have to look at them.

ChrisA