[Python-Dev] Python API version & optional features

Guido van Rossum guido@zope.com
Mon, 30 Jul 2001 10:27:32 -0400

> >  > I am not sure whether this is the right way to approach this
> >  > problem, though, since it affects all extensions -- not only
> >  > ones using Unicode.
> > 
> >   Given that unicodeobject.h defines many macros and size-sensitive
> > types in the public API, I don't see any way around this.  If the API
> > always used UCS4 (including in the macros), or defined both UCS2 and
> > UCS4 versions of everything affected, then we could get around it.
> >   That seems like a high price to pay.
> I think Guido suggested using macros to turn the Unicode APIs
> into e.g. PyUnicodeUCS4_Encode() vs. PyUnicodeUCS2_Encode().
> That would prevent loading of non-compatible extensions using Unicode
> APIs (it doesn't catch the argument parser usage, though, e.g. 
> "u").
> Perhaps that's the way to go ?!

Hm, the "u" argument parser is a nasty one to catch.  How likely is
this to be the *only* reference to Unicode in a particular extension?

I'm trying to convince myself that the magic number patch is okay, and
here's what I come up with.  If someone builds a Python with a
non-standard Unicode width and accidentally uses a directory full of
extensions built for the standard Unicode width on his platform, he
deserves a warning.  Since most extensions come with source anyway,
people who want to experiment with UCS4 will have to be more
adventurous and build all the extensions they need from source.  The
warnings will remind them.  If there's a particular extension that
they can only get in binary *and* that extension doesn't use Unicode,
they can train themselves to ignore that warning.

These warnings should use the warnings framework, by the way, to make
it easier to ignore a specific warning.  Currently it's a hard write
to stderr.

--Guido van Rossum (home page: http://www.python.org/~guido/)