[Python-Dev] subprocess.Popen and win32

David Aguilar davvid at gmail.com
Sun Apr 20 22:28:08 CEST 2014


On Sun, Apr 20, 2014 at 2:42 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Sat, 19 Apr 2014 19:02:42 -0700
> David Aguilar <davvid at gmail.com> wrote:
>>
>> On python3, this still works for normal platforms, but on windows we
>> can't pass a list of byte strings. We have to pass a list of unicode
>> strings.
>
> Windows native APIs are unicode-based. It is actually necessary to pass
> *unicode* strings, not byte strings, if you want your code to be
> correct in the face of non-ASCII characters.
>
> Under other platforms, when unicode strings are passed, Python will
> encode them using the platform's detected encoding. So, unless your
> platform is somehow misconfigured, passing unicode strings will also
> work correctly there.
>
> (note this is under Python 3)

Curious.. what if I don't want the default encoding? On UNIX, I can
control what encoding is used because I can encoding unicode strings
into bytes and the programmer is in full control. I was mainly
surprised that this is valid code on unix, but not windows, and which
seems like a portability concern.

If I use unicode strings that means I'm beholden to the default
encoding. I do agree that utf-8 (python3) is the only sane encoding
(for filesystems, etc) which is why it's just a curious question, and
for my use case, the default encoding on python3 (utf-8) is good
enough.

The projects I work on (including at work, where there is a huge
python2 code base) are python2+3 compatible by necessity, so it seems
like the best solution would be to check the python version, rather
than the platform, before deciding whether or not to encode or decode
inputs before calling into subprocess. That works for me :-)

Thanks for the explanation.

ciao,
-- 
David


More information about the Python-Dev mailing list