Thank you for reply, STINNER.

> You encode it to UTF-8 and use "\xHH\xHH\xHH..." syntax to keep ASCII
> encoding for the C file? The NAME may also be mentionned in docstrings, 
> C comments, type names, etc.

The main purpose of this issue is "I want use Cython like Python without any trouble." You don't have to worry about mentioned above. I made, and will fix when needed, the patch for Cython to convert them automatically.

The sample C codes I posted uses UTF-8 directly only OUTSIDE of the "quotation", but they can be fixed if we really have to fix. 

> I don't like the idea of a new encoding just for one very specific
> function in C. There are already too many encodings in the world :-(

Of course I will accept any encoding and/or any solution to resolve this issue. I made new encoding only to keep the condition as possible as I can, and not to limit the naming too short when using non-ASCII characters.

The patch don't include encoding-module for any purpose. For this issue, decoding is not required inside the Python. 

> The C language supports non-ASCII identifiers, but I don't know how they
> are encoded in the symbol table. 

That's why we should resolve this problem, shouldn't we? Also the standards don't define about the symbol table.

> I would prefer to rely on the C compiler if you would like to play in the
> playground of non-ASCII identifiers.

The problem is we CAN'T as you say. Or, at least, if you really think that, any ASCII limiting against dynamic loading should be removed.

>In Python/dynload_win.c, _PyImport_GetDynLoadWindows() uses GetProcAddressA().

_PyImport_GetDynLoadWindows() seems to be called only to resolve PyInit_xxx entry from _PyImport_LoadDynamicModule() in Python/importdl.c. I have already resolved with the posted patch before.

>Is it a theorical feature request, or you really have a Python module with
>a non-ASCII name?

As I told, NO to 1st, YES to 2nd. I have many '<non-ASCII>.py' which I want to convert using Cython to '<non-ASCII>.pyd' files.

> I'm not sure that it's really useful to support non-ASCII module names
> for C modules, even if I spend many months to support non-ASCII module
> names for Python modules :-)

Because you are both English and Python expert. Thanks a lot to daily Python work!

Thank you for reading this long description.