Path: csiph.com!usenet.pasdenom.info!news.redatomik.org!newsfeed.xs4all.nl!newsfeed1a.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
MIME-Version: 1.0
In-Reply-To: <8761845s2c.fsf@elektro.pacujo.net>
References: <a0a85a0a-555f-4fff-bc1f-49873dd297c5@googlegroups.com> <554AB8A5.708@davea.name> <mailman.198.1430965194.12865.python-list@python.org> <554adcf8$0$11103$c3e8da3@news.astraweb.com> <CAPTjJmq_hpk4tNYWcip88MYo8MtyV=+Y=qR-CALFUfGTEupB9A@mail.gmail.com> <mailman.200.1430983119.12865.python-list@python.org> <1c51085e-7795-4afc-9a4c-ad8b3f3a73a6@googlegroups.com> <cff48c78-07f5-43cc-82b0-5b92a866f7a8@googlegroups.com> <87ioc4k89v.fsf@elektro.pacujo.net> <CAPTjJmoeVX8zsmCfps8FxrkVFTJv61e2Pxi9evKVm1JdE3ZPDw@mail.gmail.com> <554B4C49.7010500@davea.name> <mailman.206.1430999023.12865.python-list@python.org> <87a8xgk1ad.fsf@elektro.pacujo.net> <mailman.207.1431003199.12865.python-list@python.org> <876184jyd4.fsf@elektro.pacujo.net> <mailman.208.1431007449.12865.python-list@python.org> <8761845s2c.fsf@elektro.pacujo.net>
Date: Fri, 8 May 2015 11:50:00 +1000
Subject: Re: PEP idea: On Windows, subprocess should implicitly support .bat and .cmd scripts by using FindExecutable from win32 API
From: Chris Angelico <rosuav@gmail.com>
Cc: "python-list@python.org" <python-list@python.org>
Content-Type: text/plain; charset=UTF-8
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.212.1431049809.12865.python-list@python.org>
Lines: 32
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:90110

On Fri, May 8, 2015 at 1:24 AM, Marko Rauhamaa <marko@pacujo.net> wrote:
>> That's Python's job. Abstracting away all those differences so you
>> don't have to look at them.
>
> That's the difference between our opinions: you want Python to work the
> same on different OS's. I want Python's system programming facilities to
> closely mirror those of C.

In that case, what you should do is devise an alternative language
that compiles as a thin layer over C. Have a simple translation script
that turns your code into actual C, then passes it along for
compilation. You could add whatever Python-like features you want
(memory management, maybe), but still be executing as C code. But you
don't want a high level language, if your greatest goal is "closely
mirror C".

> Take your example of subprocess.Popen. It may be essential to know that
> the communication channel is a pipe with standard pipe semantics. The
> child program might not be written in Python, after all. In fact, at
> system design level you shouldn't care what language you use as long as
> the communication interfaces are specified.

Ah, but that's a completely different thing. If you're working with a
child that isn't written in Python, then you're not working at the
level of the multiprocessing library - you're working with "I need to
give this something on its stdin and get the result back from its
stdout". For that, yes, you need something a bit more concrete; but
now it's become part of the API for that child process, whereas the
example I was giving was about the multiprocessing library, where it's
part of the implementation.

ChrisA