On 05/07/2015 06:24 AM, Chris Angelico wrote:
On Thu, May 7, 2015 at 8:10 PM, Marko Rauhamaa <ma...@pacujo.net> wrote:
Stefan Zimmermann <zimmermann.c...@gmail.com>:
And last but not least, Popen behavior on Windows makes it difficult
to write OS-independent Python code which calls external commands that
are not binary by default:
Then, write OS-dependent Python code.
I don't think it's Python's job to pave over OS differences. Java does
that by not offering precious system facilities -- very painful. Python
is taking steps in that direction, but I hope it won't go too far.
On the contrary, I think it *is* a high level language's job to pave
over those differences. Portable C code generally has to have a
whopping 'configure' script that digs into your hardware, OS, library,
etc availabilities, and lets you figure out which way to do things.
Python code shouldn't need to worry about that. You don't need to care
whether you're on a 32-bit or 64-bit computer; you don't need to care
whether it's an Intel chip or a RISCy one; you shouldn't have to
concern yourself with the difference between BSD networking and
WinSock. There'll be a handful of times when you do care, and for
those, it's nice to have some facilities exposed; but the bulk of code
shouldn't need to know about the platform it's running on.
Java went for a philosophy of "write once, run anywhere" in its early
days, and while that hasn't exactly been stuck to completely, it's
still the reasoning behind the omission of certain system facilities.
Python accepts and understands that there will be differences, so you
can't call os.getuid() on Windows, and there are a few restrictions on
the subprocess module if you want maximum portability, but the bulk of
your code won't be any different on Linux, Windows, Mac OS, OS/2,
Amiga, OS/400, Solaris, or a MicroPython board.
ChrisA
It's a nice goal. But these aren't OS features in Windows, they're
shell features. And there are several shells. If the user has
installed a different shell, is it Python's job to ignore it and
simulate what cmd.exe does?
Seems to me that's what shell=True is for. it signals Python that we're
willing to trust the shell to do whatever magic it chooses, from adding
extensions, to calling interpreters, to changing search order, to
parsing the line in strange ways, to setting up temporary environment
contexts, etc.
If there were just one shell, it might make sense to emulate its
features. Or it might make sense to contort its features to look like a
Unix shell. But with multiple possibilities, seems that's more like
space for a 3rd party library.
--
DaveA
--
https://mail.python.org/mailman/listinfo/python-list
