How to map python's unicode stuff to a wchar_t based api?
Neil Hodgson
nhodgson at bigpond.net.au
Tue Apr 27 08:15:11 EDT 2004
Ames Andreas:
> Therefore I have a default argument useUnicode and
> if possible I want to get rid of the
>
> if (PyObject_IsTrue(useUnicode)) {
> doTheUnicodeStuff();
> ...
> }
> else {
> doTheAnsiThingWhichLooksAlmostIdenticalToTheAboveButJustAlmost();
> ...
> }
>
> annoyance in almost any function.
To support Unicode file names on Win32, the convention described in PEP
277 is to call the wide API when the argument was Unicode, otherwise call
the ANSI API. From src/Modules/posixmodule.c this looks like
#ifdef Py_WIN_WIDE_FILENAMES
if (unicode_file_names()) {
PyUnicodeObject *po;
if (PyArg_ParseTuple(args, "Ui:access", &po, &mode)) {
Py_BEGIN_ALLOW_THREADS
/* PyUnicode_AS_UNICODE OK without thread lock as
it is a simple dereference. */
res = _waccess(PyUnicode_AS_UNICODE(po), mode);
Py_END_ALLOW_THREADS
return(PyBool_FromLong(res == 0));
}
/* Drop the argument parsing error as narrow strings
are also valid. */
PyErr_Clear();
}
#endif
This code then falls through to the ANSI API.
Py_WIN_WIDE_FILENAMES is only defined (in src/PC/pyconfig.h) when Python
is using 2 byte wide Unicode characters (Py_UNICODE_SIZE == 2), thus
ensuring that the result on Win32 of PyUnicode_AS_UNICODE is equivalent to
wchar_t*.
Whether PY_UNICODE_TYPE is wchar_t depends on platform and other
definitions.
The extra code required for PEP 277 adds to size and obscures intent.
Various code reduction techniques can be alleviate this such as posix_1str
in posixmodule or using some preprocessor cleverness.
Neil
More information about the Python-list
mailing list