Guido van Rossum <guido@python.org> writes: > 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. I wonder why Redhat distribute wide unicode builds? That's the immediate cause of the problem. Maybe we could ask them... Cheers, M. [*] actually, I think pygame might break with a wide unicode build. -- For every complex problem, there is a solution that is simple, neat, and wrong. -- H. L. Mencken
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4