[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [pygame] event object



Pete Shinners <shredwheat@attbi.com> writes:

> Michael Hudson wrote:
> > Then, from somewhere, you have a wide unicode build.  You need to either 
> > 
> > (a) get yourself a narrow unicode build
> >  -or-
> > (b) recompile pygame against the wide build you have installed
> > 
> > (a) can probably be achieved by going to http://www.python.org/2.2.1/
> > and downloading the RPM and (b) is presumably a matter of downloading
> > the pygame source and running "python2 setup.py install".
> 
> michael, impressive insight here, glad you knew what this was all about, 
> because it had me a bit puzzled. 

It's been a problem waiting to happen for a while (not specifically
wrt. pygame).  This is the first time I've seen it in the wild
(probably because this is the first time a wide unicode build has had
wide distribution).

> i've got a couple questions about it though.

Ah :)

> is there any way i could provide binaries that worked for both types of 
> unicode? i assume not.

I don't think so.

> here is the line of code in event.c that i'm sure is 
> the problem..
> 
> insobj(dict, "unicode", PyUnicode_FromUnicode(
> 	(Py_UNICODE*)&event->key.keysym.unicode,
> 	event->key.keysym.unicode > 0));
> 
> this is translating the "unicode" value from the SDL event to the pygame 
> event.

Careful; doesn't this assume sizeof(Py_UNICODE) == 2?  That's exactly
what's not true in a wide unicode build.

> to make things interesting, i have some crazy macros defined that 
> allow this code to compile on "pre-unicode" versions of python.
> 
> #define PyUnicode_Check(text) 0
> #define PyUnicode_AsUnicode(text) text
> #define Py_UNICODE void
> #define PyUnicode_FromUnicode(p,c) PyLong_FromLong(*(short*)(p))
> 
> 
> perhaps instead of calling the "C" versions of this function i could do the 
> work on the python side? something like
> 
> PyUnicode_FromObject(PyString_FromString((char*)&event->key.keysym.unicode));

That won't work.  PyUnicode_FromObject gets the magic API renaming
trick done to it.  Not sure why, mind.

> or even something magic like this?
> 
> PyObject *temp = Py_BuildValue("(u)", &event->key.keysym.unicode);
> PyObject *unicode = PyTuple_GET_ITEM(temp, 0);
> Py_INCREF(unicode);
> Py_DECREF(temp);

That might compile, but I doubt it will work.

What encoding does event->key.keysym.unicode have?  ucs2?

Something like

PyUnicode_Decode(&event->key.keysym.unicode, len, "UCS-2", NULL);

*ought* to be the ticket, but PyUnicode_Decode gets involved in the
API renaming scheme too.  I think I'll complain about this on
python-dev.  Not that getting it changed will help in the 2.2
timeframe...

Wild hacks like finding the builtin "unicode" object and
PyEval_CallObject-ing that may be your only hope.

> unfortunately i'm not too framiliar with the unicode stuff in python, i 
> suppose i'll need to dig into the source and see if i have an option?
> seems like a lame thing to require two versions of pygame binaries for. 
> anyone have any insight as to why redhat would use different than default 
> unicode chars?

No.  It's interesting though.

Cheers,
M.
____________________________________
pygame mailing list
pygame-users@seul.org
http://pygame.seul.org