subprocess.Popen doesn't support unicode on Windows

[peter0]

BPO	19264
Nosy	@loewis, @terryjreedy, @vstinner, @ezio-melotti, @4kir4

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2014-03-25.21:33:58.063>
created_at = <Date 2013-10-15.05:43:15.918>
labels = ['type-bug', 'library', 'expert-unicode', 'OS-windows']
title = "subprocess.Popen doesn't support unicode on Windows"
updated_at = <Date 2017-03-15.10:39:06.640>
user = 'https://bugs.python.org/peter0'

bugs.python.org fields:

activity = <Date 2017-03-15.10:39:06.640>
actor = 'Valentin LAB'
assignee = 'none'
closed = True
closed_date = <Date 2014-03-25.21:33:58.063>
closer = 'terry.reedy'
components = ['Library (Lib)', 'Unicode', 'Windows']
creation = <Date 2013-10-15.05:43:15.918>
creator = 'peter0'
dependencies = []
files = []
hgrepos = []
issue_num = 19264
keywords = []
message_count = 9.0
messages = ['199976', '200334', '214497', '214507', '214513', '214517', '214520', '214825', '289664']
nosy_count = 7.0
nosy_names = ['loewis', 'terry.reedy', 'vstinner', 'ezio.melotti', 'akira', 'peter0', 'Valentin LAB']
pr_nums = []
priority = 'normal'
resolution = 'wont fix'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue19264'
versions = ['Python 2.7']

[peter0]

On Windows, subprocess.Popen requires the executable name and working directory to be ascii. This is because it calls CreateProcess instead of CreateProcessW.

[terryjreedy]

The docs say that args should be a string or sequence of strings. It also says "On Windows, the class uses the Windows CreateProcess() function.", so it is not a bug for it to do that. However, CreateProcessW sounds like a good (and overdue, and overlooked) enhancement, if it indeed is still not used in 3.4. (Have you checked?)

On 2.7, 'string' may or may not include unicode strings. On 3.x, it definitely does, and may or may not include bytes. If 3.x restricts unicode strings to ascii text (at least on Windows), the doc should say so.

[4kir4]

I've checked the source code for 3.4; subprocess uses _winapi.CreateProcess on Windows 1 that in turn uses CreateProcessW 2. CreateProcessA is not used.

Popen should already support Unicode on Windows though I don't see explicit tests for non-ascii arguments or arguments that can't be encoded using mbcs character encoding.

[terryjreedy]

Peter, can you post 1 or more failing examplex? With some, I might be persuaded that this is a bug.

Victor, I know you have worked in this area. Any opinions?

[vstinner]

I don't understand this issue. Python 3 uses CreateProcessW() and so
support the full Unicode range. I suggest to close this issue as invalid.

Popen() parameters are Unicode strings. It may support bytes string, but
passing bytes to OS functions on Windows is deprecated, especially for
filenames.

[loewis]

The issue is really that Terry had removed 2.7 from the list of affected versions, and added 3.4 instead. The original issue was reported against 2.7, where the observation that it uses CreateProcess is correct:

http://hg.python.org/cpython/file/babb9479b79f/PC/_subprocess.c#l463

The OP's observation that this restricts the supported executable names to be ascii is incorrect. Instead, any string in the CP_ACP ("ANSI") encoding of the system would work, which practically allows to access all directories on a typical installation.

I'd close this as "won't fix", except that I recall a recent discussion that lack of Unicode support in some API is considered a bug in 2.7.

So: patches welcome (not really - I wouldn't mind if this stays open until 2.7 is properly retired).

[terryjreedy]

You're right, the bug/enhancement border for 2.7 unicode issues has been shifted a bit (or perhaps made a bit more consistent). A failing case is still needed.