Ben Finney :
> Chris Angelico writes:
>
>> On Fri, May 8, 2015 at 1:24 AM, Marko Rauhamaa 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
Chris Angelico writes:
> On Fri, May 8, 2015 at 1:24 AM, Marko Rauhamaa 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 wa
On Fri, May 8, 2015 at 1:24 AM, Marko Rauhamaa 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 facili
On Fri, May 8, 2015 at 1:14 AM, Ian Kelly wrote:
> On Thu, May 7, 2015 at 8:03 AM, Chris Angelico wrote:
>> On Thu, May 7, 2015 at 11:44 PM, Marko Rauhamaa wrote:
>>> Whole programming cultures, idioms and "right ways" differ between
>>> platforms. What's the right way to write a service (daemon
Marko Rauhamaa wrote:
> Anyway, Python has os.system() that does the quick and dirty thing you
> might be looking for.
Always invokes shell ==> overhead for .exe files
--
https://mail.python.org/mailman/listinfo/python-list
Stefan Zimmermann :
> Calling an external command should be one of the simplest tasks in a
> high level scripting language like Python.
Actually, that's quite a tricky operation in any OS. For example, bash's
simplicity is a trap that claims a lot of victims.
Anyway, Python has os.system() that
This discussion is getting really interesting and far beyond the actual topic :)
I want to add some additional thoughts on Popen:
Marko Rauhamaa wrote:
> Stefan Zimmermann:
>
> > And last but not least, Popen behavior on Windows makes it difficult
> > to write OS-independent Python code which cal
Chris Angelico :
> 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, the
On Thu, May 7, 2015 at 8:03 AM, Chris Angelico wrote:
> On Thu, May 7, 2015 at 11:44 PM, Marko Rauhamaa 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 Wind
On Thu, May 7, 2015 at 11:44 PM, Marko Rauhamaa wrote:
> Chris Angelico :
>
>>> 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, g
Chris Angelico :
>> 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
On Thu, May 7, 2015 at 10:41 PM, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> I was specifically disagreeing with the notion that it's right and
>> normal to write a bunch of platform-specific code in Python. That
>> should be the rarity.
>
> Why is that?
>
> Code is written for a specific need a
Chris Angelico :
> I was specifically disagreeing with the notion that it's right and
> normal to write a bunch of platform-specific code in Python. That
> should be the rarity.
Why is that?
Code is written for a specific need and environment. Often trying to
write generic solutions leads to cum
On Thu, May 7, 2015 at 9:28 PM, Dave Angel wrote:
> 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?
It might be an
On 05/07/2015 06:24 AM, Chris Angelico wrote:
On Thu, May 7, 2015 at 8:10 PM, Marko Rauhamaa wrote:
Stefan Zimmermann :
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
On Thu, May 7, 2015 at 8:10 PM, Marko Rauhamaa wrote:
> Stefan Zimmermann :
>
>> 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.
>
Stefan Zimmermann :
> 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
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:
2 examples:
1. I wrote a coffeetools package which wraps the CoffeeScript compiler in a
Python API. The 'coffee' command is a N
Nice to see that my topic gains that interest :)
And I see that I should have gone more into detail about what I'm actually
trying to point out.
Chris Angelico wrote:
> Hmm... hm... Ha! Found the difference. I had an explicit shebang on my
> script; yours just starts out with shell commands. That
Chris Angelico wrote:
There's a specific search order. Back in the days of DOS, it was
simply "com, then exe, then bat", but on modern Windowses, I think
it's governed by an environment variable.
You probably mean '%PATHEXT'. Mine is:
.COM;.EXE;.BAT;.BTM;.CMD;.JS;.JSE;.WSF;.WSH;.MSC;.tcl;.py;
On Thu, May 7, 2015 at 1:33 PM, Steven D'Aprano
wrote:
> On Thursday 07 May 2015 12:19, Chris Angelico wrote:
>
>> On Thu, May 7, 2015 at 10:58 AM, Dave Angel wrote:
>>> There's nothing Windows-specific about that behaviour. In Linux, there
>>> are
>>> bash commands that can only be run by using
On Thursday 07 May 2015 12:19, Chris Angelico wrote:
> On Thu, May 7, 2015 at 10:58 AM, Dave Angel wrote:
>> There's nothing Windows-specific about that behaviour. In Linux, there
>> are
>> bash commands that can only be run by using shell=True. Fortunately
>> Popen didn't make the mistake of p
On Thu, May 7, 2015 at 10:58 AM, Dave Angel wrote:
> There's nothing Windows-specific about that behaviour. In Linux, there are
> bash commands that can only be run by using shell=True. Fortunately Popen
> didn't make the mistake of pretending it's a shell.
But bash commands aren't the same as
On 05/06/2015 06:11 PM, Stefan Zimmermann wrote:
Hi.
I don't like that subprocess.Popen(['command']) only works on Windows if there
is a command.exe in %PATH%.
As a Windows user you would normally expect that also command.bat and
command.cmd can be run that way.
and command.com.
If it'
Hi.
I don't like that subprocess.Popen(['command']) only works on Windows if there
is a command.exe in %PATH%. As a Windows user you would normally expect that
also command.bat and command.cmd can be run that way.
There are simple workarounds like Popen(..., shell=True) but that is a heavy
ove
25 matches
Mail list logo
