[PATCH] windows: switch the console encoding into an encoding actually used (issue2926)

[Andrei Polushin]

29.07.2011 22:00, Adrian Buehlmann wrote:
> On 2011-07-29 02:20, Andrei Polushin wrote:
>> win32.py is hardly maintainable, it is neither a C code, nor a natural
>> Python code. It could prevent someone experimenting with code. Probably,
>> this approach suits well when you solution is rather stable.
> 
> I find the win32.py code pretty maintainable and it is heavily used and
> tested. It also runs on PyPy (and possibly other non-CPython's) and can
> be used for the pure Python version of Mercurial (see directory pure).
> 
> [...]
> 
> We've decided *against* adding more C code just to call some more
> Windows APIs in the past already when we eliminated the dependency on
> Mark Hammond's Python extensions [2] for the Mercurial 1.8 release [3]
> (see for example util.nlinks function which is implemented in win32.py
> for Windows). You can find those discussions in the archives.

It's pretty obvious why the dependency on PyWin32 should be removed. This
point seems in unrelated to the issue, it doesn't mandate removing the
dependency on C code, and it hasn't been removed at this time (am I right?).

Probably, there _could_ be an additional benefit to remove C code entirely,
but let's consider whether it could be done in principle. I see a couple of
problems going this way, think about this:

1. What if Mercurial will to switch to Unicode Windows APIs?
   Will you start rewriting declarations of CreateFileA, CreateHardLinkA,
   SetFileAttributesA, GetModuleFileNameA, CreateProcessA, RegOpenKeyExA,
   RegQueryValueExA (all from win32.py) into their Unicode equivalents?

2. How would you switch the declarations (C code does this simply with
   #define UNICODE)?

3. What about Unicode/ANSI structure changes? Do you plan to pull all
   necessary structures manually, in several forms?

4. What about structure changes with different Windows API versions?

5. What about introducing subtle binary compatibility bugs while pulling
   a bunch of declarations from <windows.h>?

6. What about switching to pure Win64 APIs? Does it require changing
   exports from kernel32 into something like kernel64?

This is just to show that it's _not_ maintainable if your are either
qualified C/C++ programmer or a qualified Python programmer. This would
require a somehow unique skill of how to pull declarations from <windows.h>
into ctypes-based Python code, taking a great care of all that sort of
binary compatibility problems.

This work is for an automatic tool, not for an eventual contributor like me.

> You see the result of these decisions in the ctypes code I wrote in
> win32.py, which was reviewed by crew member Patrick, and the decisions
> accepted by Matt.
> 
> I see no reason (yet) here to revisit those decisions and suddenly
> decide to go in the opposite direction, and start adding C code for
> calling these few Windows APIs.

I didn't get what the decision has been made exactly. Are there any plans to
eliminate the C code entirely? Is it feasible in principle?

--
Andrei Polushin