On Sun, Apr 20, 2014 at 2:42 AM, Antoine Pitrou <solip...@pitrou.net> wrote: > On Sat, 19 Apr 2014 19:02:42 -0700 > David Aguilar <dav...@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 _______________________________________________ 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
