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

[Martin v. Loewis]

Guido van Rossum <guido@python.org> writes:

> Maybe because other macros are often disallowed in (3rd party)
> extensions, the reason being that the macros dig in the internal
> representation which isn't guaranteed to be binary compatible?  

In this specific case, using a function vs. using a macro makes no
difference: the function exposes implementation details just as the
macro. In theory, using the function would allow to rearrange Unicode
objects to have their characters in the same memory block as the
object, which would break applications of the macro - but apparently,
the risk of the result relying too much on implementation details
(i.e. wide or narrow Unicode) is more serious.

> It would make sense that the same rules applies to the Unicode
> macros in 3rd party extensions.

Given the potential change of the layout of Unicode objects, I would
agree that it is good to ban PyUnicode_UPPER_CASE from use in
extension modules.

> If there was a way so that only extensions that use the macros or
> APIs whose signature uses Py_UNICODE_TYPE would fail to load, that
> would be better.  But I don't know how to enforce that.

That is indeed the problem, and the last time we concluded that it
would be best to bind all Unicode functions to the unicode width, to
be on the safe side.

> Maybe it goes too far.
> 
> OTOH, Michael, is this really something you cannot live with?  Or is
> it simply a surprise?

That is the central question here. As I said before, I would expect
this to be a non-issue, in real life.

Regards,
Martin