On 14 November 2012 13:35 Francois Duranleau [mailto:xiao.bai.xiong@gmail.com] wrote :-
Isn't this more an implementation issue rather than an API issue? I mean, the underlying implementation could easily convert an input UTF8 string to UTF16 string before making the call to CreateProcess? Granted, though, the command line string version should probably also support wide char strings.
Sorry was unclear - Think it's both an implementation issue in python and a problem with interface. It’s a similar problem to why boost filesystem returns path objects rather than strings see http://www.boost.org/doc/libs/1_52_0/libs/filesystem/doc/tutorial.html#Class... const char * p = "foo my_file"; std:string s("foo my_file"); Aren't explicit about what encoding the string is using (eg utf8 or 8 bit using the current systems code page) - whilst 8 bit code pages are probably only of use for backwards compatibility for systems which care a lot about this (eg windows) any x-platform library would have to support specifying the encoding somehow (and possibly also what encoding foo is expecting to be called with) - Whilst this can be done cleanly using iostreams and boost locale - the simple passing a command line string is probably too flawed to be useful imho. Alex