Unicode entries on sys.path

[Thomas Heller]

"Martin v. Löwis" <martin at v.loewis.de> writes:

> Thomas Heller wrote:
>> How should these patches be approached?
>
> Please have a look as to how posixmodule.c and fileobject.c deal with
> this issue.
>
>> On windows, it would probably
>> be easiest to use the MS generic text routines: _tcslen instead of
>> strlen, for example, and to rely on the _UNICODE preprocessor symbol to
>> map this function to strlen or wcslen.
>
> No. This fails for two reasons:
> 1. We don't compile Python with _UNICODE, and never will do so. This
>     macro is only a mechanism to simplify porting code from ANSI APIs
>     to Unicode APIs, so you don't have to reformulate all the API calls.
>     For new code, it is better to use the Unicode APIs directly if you
>     plan to use them.
> 2. On Win9x, the Unicode APIs don't work (*). So you need to chose at
>     run-time whether you want to use wide or narrow API. Unless
>     a) we ship two binaries in the future, one for W9x, one for NT+
>        (I hope this won't happen), or
>     b) we drop support for W9x. I'm in favour of doing so sooner or
>        later, but perhaps not for Python 2.5.

I wasn't asking about the *W functions, I'm asking about string/unicode
handling in Python source files. Looking into Python/import.c, wouldn't
it be required to change the signature of a lot of functions to receive
PyObject* arguments, instead of char* ?
For example, find_module should change from
  static struct filedescr *find_module(char *, char *, PyObject *,
                                       char *, size_t, FILE **, PyObject **);

to 

  static struct filedescr *find_module(char *, char *, PyObject *,
                                       PyObject **, FILE **, PyObject **);

where the fourth argument would now be either a PyString or PyUnicode
object pointer?

> (*) Can somebody please report whether the *W file APIs fail on W9x
> because the entry points are not there (so you can't even run the
> binary), or because they fail with an error when called?

I always thought that the *W apis would not be there in win98, but it
seems that is wrong.  Fortunately, how could Python, which links to the
FindFirstFileW exported function for example, run on win98 otherwise...

Thomas