On 12 June 2014 05:34, Florian Bruhin wrote:
> Do the lookup in PATH yourself, it's not like that's rocket science.
Am I missing something here? I routinely do
subprocess.check_call(['hg', 'update']) or whatever, and it finds the
hg executable fine.
Paul
_
* anatoly techtonik [2014-06-12 02:00:55 +0300]:
> On Thu, Jun 12, 2014 at 1:30 AM, Chris Angelico wrote:
>
> > Why pass shell=True when executing a single
> > command? I don't get it.
> >
>
> I don't know about Linux, but on Windows programs are not directly
> available as /usr/bin/python, so
On Wed, Jun 11, 2014 at 9:43 PM, Ethan Furman wrote:
> On 06/11/2014 07:12 PM, Chris Angelico wrote:
>>
>> On Thu, Jun 12, 2014 at 12:07 PM, Chris Angelico wrote:
>>>
>>> ISTM what you want is not shell=True, but a separate function that
>>> follows the system policy for translating a command nam
On 06/11/2014 07:12 PM, Chris Angelico wrote:
On Thu, Jun 12, 2014 at 12:07 PM, Chris Angelico wrote:
ISTM what you want is not shell=True, but a separate function that
follows the system policy for translating a command name into a
path-to-binary. That's something that, AFAIK, doesn't currentl
On Thu, Jun 12, 2014 at 12:07 PM, Chris Angelico wrote:
> ISTM what you want is not shell=True, but a separate function that
> follows the system policy for translating a command name into a
> path-to-binary. That's something that, AFAIK, doesn't currently exist
> in the Python 2 stdlib, but Pytho
On Thu, Jun 12, 2014 at 10:00 AM, anatoly techtonik wrote:
> I thought exactly about that. Usually separate arguments are used to avoid
> problems with escaping of quotes and other stuff.
>
> I'd deprecate subprocess and split it into separate modules. One is about
> shell execution and another on
On Wed, Jun 11, 2014, at 17:11, Nikolaus Rath wrote:
> MRAB writes:
> > On 2014-06-11 02:30, Nikolaus Rath wrote:
> >> Hello,
> >>
> >> I recently noticed (after some rather protacted debugging) that the
> >> io.IOBase class comes with a destructor that calls self.close():
> >>
> >> [0] nikratio@v
On Thu, Jun 12, 2014 at 2:00 AM, R. David Murray
wrote:
> Also notice that using a list with shell=True is using the API
> incorrectly. It wouldn't even work on Linux, so that torpedoes
> the cross-platform concern already :)
>
> This kind of confusion is why I opened http://bugs.python.org/issu
MRAB writes:
> On 2014-06-11 02:30, Nikolaus Rath wrote:
>> Hello,
>>
>> I recently noticed (after some rather protacted debugging) that the
>> io.IOBase class comes with a destructor that calls self.close():
>>
>> [0] nikratio@vostro:~/tmp$ cat test.py
>> import io
>> class Foo(io.IOBase):
>>
On Thu, Jun 12, 2014 at 1:30 AM, Chris Angelico wrote:
> Why pass shell=True when executing a single
> command? I don't get it.
>
I don't know about Linux, but on Windows programs are not directly
available as /usr/bin/python, so you need to find command in PATH
directories. Passing shell=True m
On Thu, Jun 12, 2014 at 1:30 AM, Chris Angelico wrote:
> On Thu, Jun 12, 2014 at 7:58 AM, Ryan wrote:
> > In all seriousness, to me this is obvious. When you pass a command to the
> > shell, naturally, certain details are shell-specific.
>
On Windows cmd.exe is used by default:
http://hg.python
Also notice that using a list with shell=True is using the API
incorrectly. It wouldn't even work on Linux, so that torpedoes
the cross-platform concern already :)
This kind of confusion is why I opened http://bugs.python.org/issue7839.
On Wed, 11 Jun 2014 16:58:30 -0500, Ryan wrote:
> Of cours
On Wed, Jun 11, 2014, at 13:26, anatoly techtonik wrote:
> I am banned from tracker, so I post the bug here:
Being banned from the tracker is not an invitation to use python-dev@ as
one.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.pyth
On Thu, Jun 12, 2014 at 7:58 AM, Ryan wrote:
> In all seriousness, to me this is obvious. When you pass a command to the
> shell, naturally, certain details are shell-specific.
>
> -1. Bad idea. Very bad idea. If you want the ^ to be escaped, do it
> yourself. Or better yet, don't pass shell=T
Of course! And, why not escape everything else, too?
abc -> ^a^b^c
echo %PATH% -> ^e^c^h^o^ ^%^P^A^T^H^%
In all seriousness, to me this is obvious. When you pass a command to the
shell, naturally, certain details are shell-specific.
-1. Bad idea. Very bad idea. If you want the ^ to be esca
I am banned from tracker, so I post the bug here:
Normal Windows behavior:
>hg status --rev ".^1"
M mercurial\commands.py
? pysptest.py
>hg status --rev .^1
abort: unknown revision '.1'!
So, ^ is an escape character. See
http://www.tomshardware.co.uk/forum/35565-45-when-special-comman
On 6/11/2014 9:27 AM, Ben Hoyt wrote:
What would be the next steps to get this to happen? Open an issue on
bugs.python.org and submit a patch with tests?
Yep!
Okay, I've done step one (opened an issue on bugs.python.org), and
hope to provide a patch in the next few weeks if no-one else does
(
Le 11/06/2014 10:28, Victor Stinner a écrit :
Hi,
I'm working on asyncio and it's difficult to debug code because
@asyncio.coroutine decorator removes the name of the function if the
function is not a generator (if it doesn't use yield from).
I propose to add new gi_name and gi_qualname fields
Hi,
I'm working on asyncio and it's difficult to debug code because
@asyncio.coroutine decorator removes the name of the function if the
function is not a generator (if it doesn't use yield from).
I propose to add new gi_name and gi_qualname fields to the C structure
PyGenObject, add a new __qual
>> What would be the next steps to get this to happen? Open an issue on
>> bugs.python.org and submit a patch with tests?
>
> Yep!
Okay, I've done step one (opened an issue on bugs.python.org), and
hope to provide a patch in the next few weeks if no-one else does
(I've never compiled CPython on Wi
On 11 Jun 2014 12:31, "Antoine Pitrou" wrote:
>
> Le 10/06/2014 21:30, Nikolaus Rath a écrit :
>
>>
>> For me, having __del__ call close() does not qualify as a reasonable
>> default implementation unless close() is required to be idempotent
>> (which one could deduce from the documentation if one
21 matches
Mail list logo
