Unicode entries on sys.path

[vincent wehren]

Thomas Heller wrote:
> "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...

Normally I would have thought this would require using the Microsoft 
Layer for Unicode (unicows.dll).

According to MSDN 9x already does have a handful of unicode APIs.

FindFirstFile does not seem to be one of them - unless the list on

htpp://msdn.microsoft.com/library/default.asp?url=/library/en-us/mslu/winprog/other_existing_unicode_support.asp)

is bogus (?).

--

Vincent Wehren



> 
> Thomas