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

[Guido van Rossum]

> > OTOH, Michael, is this really something you cannot live with?  Or is
> > it simply a surprise?
> 
> Here's where the problem came up.
> 
> A user posted to pygame-users saying that when he tried to import
> pygame.event, along the lines of PyUnicodeUCS2_Unicode undefined.
> This obviously made a light go on in my head, and I asked where he'd
> got his Python and his pygame.  He'd got his Python from the Redhat
> 7.3 RPM and his pygame from pygame.org.  I suggested building pygame
> from source, which he did and everything worked[*].  
> 
> Prediction: this is going to cause pain.  For instance, if this user
> decides that he wants to upgrade to 2.2.1, he might download Sean's
> RPMs from python.org which are narrow unicode builds -- and then his
> extensions will break.  The problem here is that the kind of users
> this is going to trouble are exactly the users who will not know
> what's going on.
> 
> We can't prevent this sort of thing totally, but I think it should be
> possible to carry out simple unicode manipulations (like this example
> of returning a buffer) without incurring this kind of binary
> compatibility worry.  Maybe a "safe" api, plastered with warning signs
> in the docs about poking into the internal structure of the objects.

That might work.  Or you could call the Python APIs from C. :-)

> I wonder why Redhat distribute wide unicode builds?  That's the
> immediate cause of the problem.  Maybe we could ask them...

I've had little luck trying to communicate with RedHat about their
Python releases.

Anyway, I think it's obvious why they do this: because it's there, and
because they don't want surprises with customers who use wide Unicode
characters.

> Cheers,
> M.
> [*] actually, I think pygame might break with a wide unicode build.

Hm, so maybe you should fix that first before you start complaining.

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