[Python-Dev] Removal of Win32 ANSI API

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 PyUnicode_FSDecoder, 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:
>>>> arg_is_bytes = not isinstance(arg, str)
>> if arg_is_bytes:
>> val = _decode_mbcs(arg)
>> # Decoding error checking here
>> else:
>> val = arg
>> # Common processing using WIDE API
>> if arg_is_bytes:
>> result = _encode_mbcs(wide_result)
>> # Encoding error checking here
>> else:
>> result = wide_result
>> 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?