Re: [Modeling-users] type('') and unicode
Status: Abandoned
Brought to you by:
sbigaret
From: <so...@la...> - 2003-07-16 15:48:08
|
On Wed, Jul 16, 2003 at 11:08:30AM -0400, Yannick Gingras wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > I stumbled upon some "if type(foo)==type(''):" in the code > (grep -r -E "type\(''\)" .). This fail to match unicode that behave > like as string but is not the same type : > > >>> type(u'') == type('') > 0 > > Is this some kind of obscure feature ? > > This is used in the Qualifier code and it seems likely to me that > someone will eventually try to make a fetch with unicode. In fact I > might just try that right now... > > UnicodeError: ASCII encoding error: ordinal not in range(128) > > Argh ! U get this cause you try to to something like this ' %s ' % my_unicode Could you please give us a bigger traceback. I talk w/ Sebastian last week about this. In fact i got some trouble w/ mysql and unicode (not using modeling), and ask him what he did to cover this issue in modeling. It's really seem that modeling doesn't take care about unicode. (Read : Seb hasn't done so much test about unicode ) I haven't done so much test but i think that stuff like enabling LOG will generate a lot of Unicode traceback > there is "type(foo) in (type(''), type(u''))" or I could encode my > query or who knows what. Since some RDMS (aka MySQL) choke on > unicode, maybe it would be best to have every queries encoded in utf-8 > but I prefer to have your opinion 1st. Another trick that might help you is that MySQL 4.0 support unicode in query. but the MySQLDB don't by default. In fact you can pass a special encoding charset at connection but you need to have a latest version of the package ( I have to re-build this from source on my debian since it isn't in the default unstable install) Bye Bye . |