Re: [Python-Dev] subprocess shell=True on Windows doesn't escape ^ character
On 15/06/2014 02:22, Ryan Gonzalez wrote: Of course cmd.exe is hardcoded; Of course it's not: (from Lib/subprocess.py) comspec = os.environ.get(COMSPEC, cmd.exe) I don't often expect, in these post-command.com days, to get anything other than cmd.exe. But alternative command processors are certainly possible. TJG ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Why does _pyio.*.readinto have to work with 'b' arrays?
On 15 June 2014 14:57, Nikolaus Rath nikol...@rath.org wrote:
On 06/14/2014 09:31 PM, Nick Coghlan wrote:
On 15 June 2014 10:41, Benjamin Peterson benja...@python.org wrote:
On Sat, Jun 14, 2014, at 15:39, Nikolaus Rath wrote:
It seems to me that a much cleaner solution would be to simply declare
_pyio's readinto to only work with bytearrays, and to explicitly raise a
(more helpful) TypeError if anything else is passed in.
That seems reasonable. I don't think _pyio's behavior is terribly
important compared to the C _io module.
_pyio was written before the various memoryview fixes that were
implemented in Python 3.3 - it seems to me it would make more sense to
use memoryview to correctly handle arbitrary buffer exporters (we
implemented similar fixes for the base64 module in 3.4).
Definitely. But is there a way to do that without writing C code?
Yes, Python level reshaping and typecasting of memory views is one of
the key enhancements Stefan implemented for 3.3.
from array import array
a = array('b', b'x'*10)
am = memoryview(a)
a
array('b', [120, 120, 120, 120, 120, 120, 120, 120, 120, 120])
am[:3] = memoryview(b'foo').cast('b')
a
array('b', [102, 111, 111, 120, 120, 120, 120, 120, 120, 120])
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] subprocess shell=True on Windows doesn't escape ^ character
On 15 June 2014 00:15, Greg Ewing greg.ew...@canterbury.ac.nz wrote: However, it says the Windows version uses CreateProcess, which doesn't use PATH. Huh? CreateProcess uses PATH: py -3.4 Python 3.4.0 (v3.4.0:04f714765c13, Mar 16 2014, 19:25:23) [MSC v.1600 64 bit (AMD64)] on win32 Type help, copyright, credits or license for more information. import subprocess subprocess.check_call(['echo', 'hello']) hello 0 echo is an executable C:\Utils\GnuWin64\echo.exe which is on PATH but not in the current directory... Paul ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] subprocess shell=True on Windows doesn't escape ^ character
On 15/06/2014 08:54, Paul Moore wrote:
On 15 June 2014 00:15, Greg Ewing greg.ew...@canterbury.ac.nz wrote:
However, it says the Windows version uses CreateProcess, which
doesn't use PATH.
Huh? CreateProcess uses PATH:
Just to be precise:
CreateProcess *doesn't* use PATH if you pass an lpApplicationName
parameter. It *does* use PATH if you pass a lpCommandLine parameter
without an lpApplicationName parameter. It's possible to do either via
the subprocess module, but the latter is the default.
If you call:
subprocess.Popen(['program.exe', 'a', 'b'])
or
subprocess.Popen('program.exe a b'])
Then CreateProcess will be called with a lpCommandLine but no
lpApplicationName and PATH will be searched.
If, however, you call:
subprocess.Popen(['a', 'b'], executable=program.exe)
then CreateProcess will be called with lpApplicationName=program.exe
and lpCommandLine=a b and the PATH will not be searched.
TJG
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Why does _pyio.*.readinto have to work with 'b' arrays?
Le 15 juin 2014 02:42, Benjamin Peterson benja...@python.org a écrit : On Sat, Jun 14, 2014, at 15:39, Nikolaus Rath wrote: It seems to me that a much cleaner solution would be to simply declare _pyio's readinto to only work with bytearrays, and to explicitly raise a (more helpful) TypeError if anything else is passed in. That seems reasonable. I don't think _pyio's behavior is terribly important compared to the C _io module. Which types are accepted by the readinto() method of the C io module? If the C module only accepts bytearray, the array hack must be removed from _pyio. The _pyio module is mostly used for testing purpose, it's much slower. I hope that nobody uses it in production, the module is private (underscore prefix). So it's fine to break backward compatibilty to have the same behaviour then the C module. Victor ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] subprocess shell=True on Windows doesn't escape ^ character
Paul Moore wrote: Huh? CreateProcess uses PATH: Hmm, in that case Microsoft's documentation is lying, or subprocess is doing something itself before passing the command name to CreateProcess. Anyway, looks like there's no problem. -- Greg ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Why does _pyio.*.readinto have to work with 'b' arrays?
Nick Coghlan ncogh...@gmail.com writes: On 15 June 2014 14:57, Nikolaus Rath nikol...@rath.org wrote: On 06/14/2014 09:31 PM, Nick Coghlan wrote: On 15 June 2014 10:41, Benjamin Peterson benja...@python.org wrote: On Sat, Jun 14, 2014, at 15:39, Nikolaus Rath wrote: It seems to me that a much cleaner solution would be to simply declare _pyio's readinto to only work with bytearrays, and to explicitly raise a (more helpful) TypeError if anything else is passed in. That seems reasonable. I don't think _pyio's behavior is terribly important compared to the C _io module. _pyio was written before the various memoryview fixes that were implemented in Python 3.3 - it seems to me it would make more sense to use memoryview to correctly handle arbitrary buffer exporters (we implemented similar fixes for the base64 module in 3.4). Definitely. But is there a way to do that without writing C code? Yes, Python level reshaping and typecasting of memory views is one of the key enhancements Stefan implemented for 3.3. [..] Ah, nice. I'll use that. Thank you Stefan :-). Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Why does _pyio.*.readinto have to work with 'b' arrays?
Victor Stinner victor.stin...@gmail.com writes: Le 15 juin 2014 02:42, Benjamin Peterson benja...@python.org a écrit : On Sat, Jun 14, 2014, at 15:39, Nikolaus Rath wrote: It seems to me that a much cleaner solution would be to simply declare _pyio's readinto to only work with bytearrays, and to explicitly raise a (more helpful) TypeError if anything else is passed in. That seems reasonable. I don't think _pyio's behavior is terribly important compared to the C _io module. Which types are accepted by the readinto() method of the C io module? Everything implementing the buffer protocol. If the C module only accepts bytearray, the array hack must be removed from _pyio. _pyio currently accepts only bytearray and 'b'-type arrays. But it seems with memoryview.cast() we now have a way to make it behave like the C module. Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
