RetroSearch Browse

Fri Nov 12 13:08:30 CET 2010 · https://mail.python.org/pipermail/python-dev/2010-November/105536.html

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...

Victor

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2010-November/105536.html below:

[Python-Dev] Removal of Win32 ANSI API