Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #90077 > unrolled thread

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

Back to article view | Back to comp.lang.python

Contents

  PEP idea: On Windows, subprocess should implicitly support .bat and .cmd scripts by using FindExecutable from win32 API Stefan Zimmermann <zimmermann.code@gmail.com> - 2015-05-06 15:11 -0700
    Re: PEP idea: On Windows, subprocess should implicitly support .bat and .cmd scripts by using FindExecutable from win32 API Dave Angel <davea@davea.name> - 2015-05-06 20:58 -0400
    Re: PEP idea: On Windows, subprocess should implicitly support .bat and .cmd scripts by using FindExecutable from win32 API Chris Angelico <rosuav@gmail.com> - 2015-05-07 12:19 +1000
      Re: PEP idea: On Windows, subprocess should implicitly support .bat and .cmd scripts by using FindExecutable from win32 API Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-05-07 13:33 +1000
        Re: PEP idea: On Windows, subprocess should implicitly support .bat and .cmd scripts by using FindExecutable from win32 API Chris Angelico <rosuav@gmail.com> - 2015-05-07 13:57 +1000
        Re: PEP idea: On Windows, subprocess should implicitly support .bat and .cmd scripts by using FindExecutable from win32 API Gisle Vanem <gvanem@yahoo.no> - 2015-05-07 09:15 +0200
          Re: PEP idea: On Windows, subprocess should implicitly support .bat and .cmd scripts by using FindExecutable from win32 API Stefan Zimmermann <zimmermann.code@gmail.com> - 2015-05-07 02:38 -0700
            Re: PEP idea: On Windows, subprocess should implicitly support .bat and .cmd scripts by using FindExecutable from win32 API Stefan Zimmermann <zimmermann.code@gmail.com> - 2015-05-07 03:03 -0700
              Re: PEP idea: On Windows, subprocess should implicitly support .bat and .cmd scripts by using FindExecutable from win32 API Marko Rauhamaa <marko@pacujo.net> - 2015-05-07 13:10 +0300
                Re: PEP idea: On Windows, subprocess should implicitly support .bat and .cmd scripts by using FindExecutable from win32 API Chris Angelico <rosuav@gmail.com> - 2015-05-07 20:24 +1000
                Re: PEP idea: On Windows, subprocess should implicitly support .bat and .cmd scripts by using FindExecutable from win32 API Dave Angel <davea@davea.name> - 2015-05-07 07:28 -0400
                Re: PEP idea: On Windows, subprocess should implicitly support .bat and .cmd scripts by using FindExecutable from win32 API Chris Angelico <rosuav@gmail.com> - 2015-05-07 21:43 +1000
                  Re: PEP idea: On Windows, subprocess should implicitly support .bat and .cmd scripts by using FindExecutable from win32 API Marko Rauhamaa <marko@pacujo.net> - 2015-05-07 15:41 +0300
                    Re: PEP idea: On Windows, subprocess should implicitly support .bat and .cmd scripts by using FindExecutable from win32 API Chris Angelico <rosuav@gmail.com> - 2015-05-07 22:53 +1000
                      Re: PEP idea: On Windows, subprocess should implicitly support .bat and .cmd scripts by using FindExecutable from win32 API Marko Rauhamaa <marko@pacujo.net> - 2015-05-07 16:44 +0300
                        Re: PEP idea: On Windows, subprocess should implicitly support .bat and .cmd scripts by using FindExecutable from win32 API Chris Angelico <rosuav@gmail.com> - 2015-05-08 00:03 +1000
                          Re: PEP idea: On Windows, subprocess should implicitly support .bat and .cmd scripts by using FindExecutable from win32 API Marko Rauhamaa <marko@pacujo.net> - 2015-05-07 18:24 +0300
                            Re: PEP idea: On Windows, subprocess should implicitly support .bat and .cmd scripts by using FindExecutable from win32 API Stefan Zimmermann <zimmermann.code@gmail.com> - 2015-05-07 08:45 -0700
                              Re: PEP idea: On Windows, subprocess should implicitly support .bat and .cmd scripts by using FindExecutable from win32 API Marko Rauhamaa <marko@pacujo.net> - 2015-05-07 21:13 +0300
                                Re: PEP idea: On Windows, subprocess should implicitly support .bat and .cmd scripts by using FindExecutable from win32 API Stefan Zimmermann <zimmermann.code@gmail.com> - 2015-05-07 16:27 -0700
                            Re: PEP idea: On Windows, subprocess should implicitly support .bat and .cmd scripts by using FindExecutable from win32 API Chris Angelico <rosuav@gmail.com> - 2015-05-08 11:50 +1000
                            Re: PEP idea: On Windows, subprocess should implicitly support .bat and .cmd scripts by using FindExecutable from win32 API Ben Finney <ben+python@benfinney.id.au> - 2015-05-08 12:26 +1000
                              Re: PEP idea: On Windows, subprocess should implicitly support .bat and .cmd scripts by using FindExecutable from win32 API Marko Rauhamaa <marko@pacujo.net> - 2015-05-08 09:14 +0300
                        Re: PEP idea: On Windows, subprocess should implicitly support .bat and .cmd scripts by using FindExecutable from win32 API Ian Kelly <ian.g.kelly@gmail.com> - 2015-05-07 09:14 -0600
                        Re: PEP idea: On Windows, subprocess should implicitly support .bat and .cmd scripts by using FindExecutable from win32 API Chris Angelico <rosuav@gmail.com> - 2015-05-08 11:46 +1000

Page 2 of 2 — ← Prev page 1 [2]

#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

[toc] | [prev] | [next] | [standalone]

#90112

Chris Angelico <rosuav@gmail.com> writes:

> 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. […] But you don't want a high
> level language, if your greatest goal is "closely mirror C".

+1.

Marko, you have many times criticised Python on the basis, essentially,
that it is not some other platform. It's quite unproductive, and leads
only to discussions that are at best frustrating for all involved.

If you want a platform that is fundamentally different from Python,
there are plenty available for you. Arguing that Python should be
fundamentally different will not avail us anything good.

-- 
 \      “Anyone who believes exponential growth can go on forever in a |
  `\        finite world is either a madman or an economist.” —Kenneth |
_o__)                                                         Boulding |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#90119

Ben Finney <ben+python@benfinney.id.au>:

> Chris Angelico <rosuav@gmail.com> writes:
>
>> 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. […] But you don't want a high
>> level language, if your greatest goal is "closely mirror C".
>
> +1.
>
> Marko, you have many times criticised Python on the basis,
> essentially, that it is not some other platform. It's quite
> unproductive, and leads only to discussions that are at best
> frustrating for all involved.
>
> If you want a platform that is fundamentally different from Python,
> there are plenty available for you. Arguing that Python should be
> fundamentally different will not avail us anything good.

I don't. Python *does* provide OS-dependent facilities. Somebody
complained about that. I said Python was the way it should be, even
though there are signs Python "wants" to become more Java-esque.

For example, Python provides the errno module. Its use and meanings can
be looked up with man pages.

So Python has the great advantage that it *can* be used as a Linux
system programming language. And I am.


Marko

[toc] | [prev] | [next] | [standalone]

#90103

On Thu, May 7, 2015 at 8:03 AM, Chris Angelico <rosuav@gmail.com> wrote:
> On Thu, May 7, 2015 at 11:44 PM, Marko Rauhamaa <marko@pacujo.net> wrote:
>> 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.

https://www.python.org/dev/peps/pep-3143/

[toc] | [prev] | [next] | [standalone]

#90109

On Fri, May 8, 2015 at 1:14 AM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
> On Thu, May 7, 2015 at 8:03 AM, Chris Angelico <rosuav@gmail.com> wrote:
>> On Thu, May 7, 2015 at 11:44 PM, Marko Rauhamaa <marko@pacujo.net> wrote:
>>> 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.
>
> https://www.python.org/dev/peps/pep-3143/

Precisely. It's definitely within the language's purview; that that
PEP is deferred is not due to it being a bad idea for the
language/stdlib to deal with these differences.

ChrisA

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.python

csiph-web