Re: [Python-Dev] Why does _pyio.*.readinto have to work with 'b' arrays?
Victor Stinner writes: > Le 15 juin 2014 02:42, "Benjamin Peterson" 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
Re: [Python-Dev] Why does _pyio.*.readinto have to work with 'b' arrays?
Nick Coghlan writes: > On 15 June 2014 14:57, Nikolaus Rath wrote: >> On 06/14/2014 09:31 PM, Nick Coghlan wrote: >>> On 15 June 2014 10:41, Benjamin Peterson 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] 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?
Le 15 juin 2014 02:42, "Benjamin Peterson" 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
On 15/06/2014 08:54, Paul Moore wrote:
On 15 June 2014 00:15, Greg Ewing 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] subprocess shell=True on Windows doesn't escape ^ character
On 15 June 2014 00:15, Greg Ewing 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
