[Python-Dev] Removal of Win32 ANSI API (original) (raw)

Hirokazu Yamamoto ocean-city at m2.ccsnet.ne.jp
Sat Nov 13 17:21:37 CET 2010

On 2010/11/12 4:26, Victor Stinner wrote:

On Thursday 11 November 2010 17:07:28 Hirokazu Yamamoto wrote:

Hello. Is it possible to remove Win32 ANSI API (ie: GetFileAttributesA) and only use Win32 WIDE API (ie: GetFileAttributesW)? Mainly in posixmodule.c.

Even if I hate the MBCS encoding, because it replaces undecodable characters by similar glyphs by default, I'm not certain that it is a good idea to drop the bytes API.

On 2010/11/12 21:08, Victor Stinner wrote:

On Thursday 11 November 2010 23:01:32 you wrote:

Sure, it will divide the number of lines, of the code specific to Windows, by two.

Can we get most of the code cleanup benefit without the backwards compatibility risk by doing the decode from 'mbcs' on our side of the fence? I created PyUnicodeFSDecoder, a ParseTuple converter used to work on unicode paths, instead of bytes paths. On Windows, this converter uses mbcs encoding in strict mode, whereas Windows converter uses replace error handler to decode, and ignore to encode. So I don't think that we should this converter on Windows. That is, have code that was the C equivalent of: argisbytes = not isinstance(arg, str) if argisbytes: val = decodembcs(arg) # Decoding error checking here else: val = arg # Common processing using WIDE API if argisbytes: result = encodembcs(wideresult) # Encoding error checking here else: result = wideresult This doesn't make the code shorter, it may be longer than the actual code, and it is less compliant with the Windows native API...

Is it possible to implement new PyArg_ParseTuple converter to use PyUnicode_Decode(const char *s, Py_ssize_t size, const char encoding, / mbcs */ const char errors) / replace */ and use it?

More information about the Python-Dev mailing list