[Python-Dev] The C API and wide unicode support

[Michael Hudson]

It may be best to allow this particular dead horse to go on being
dead, but I thought I'd ask here.  Beats work, anyway.

Picture the situation: you're wrapping a C library that returns a
unicode string (let's say encoded as UCS-2).  You want to return this
as a Python object.  So you'd think you can write

return PyUnicode_Decode(encstr, "ucs-2", NULL);

(or something close to that).  But for reasons that escape me,
PyUnicode_Decode is included in the API renaming in
Include/unicodeobject.h, so if you want to provide binaries you have
to provide two, and you can be sure that users will have no idea which
they need.

So, questions:

(1) am I correct in thinking that PyUnicode_Decode (and a bunch of
    others) could safely be omitted from the renaming?
(2) if so, is it worth omitting those APIs that could be omitted for 2.3?

This train of thinking came about because the version of 2.2 that
comes with Redhat 7.3 is compiled with wide unicode support (which
surprised me), and so the pygame RPMs broke.

Cheers,
M.

-- 
  Any form of evilness that can be detected without *too* much effort
  is worth it...  I have no idea what kind of evil we're looking for
  here or how to detect is, so I can't answer yes or no.
                                       -- Guido Van Rossum, python-dev