>>> * Replace Windows API calls with wide versions to support unicode >>> for file names, environment etc. >> +1. This should be broken into separate tasks for each API. > > What are we referring to here? Calling the W versions explicitly and > using wchar_t for everything, or using the TCHAR/TEXT() approach and > keeping the API calls the same, letting the #define UNICODE do the > work behind the scenes?
Not sure whose being attributed here, but I think "breaking down" should be done by "information source": command line, environment, registry, file names, sys.path, module names, etc. I have a patch on SF to resolve the command line issue. I don't think we should use Microsoft's Unicode programming model around TCHAR/TEXT. It would allow for two different builds, and given that we don't need to support W9X anymore, an "ANSI" build is pointless, IMO. Regards, Martin _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
