Malcolm Tredinnick wrote: > On Wed, 2007-08-29 at 14:58 +0100, Robin Becker wrote: >> Hi, we're having some troubles with latest django that are caused by the >> switch >> to unicode string output. In particular since we were already carefully >> handling >> the conversion and encoding of the database values we are now getting errors >> because the data is in unicode. Is it possible to disable the unicode >> conversion? > > No, it's not possible. The assumptions that strings will already be > Unicode is fairly tightly inter-twined throughout the code. To do > otherwise would, for example, really impact performance because we would > *never* be able to assume that things were in the right encoding and > have to call smart_unicode() everywhere -- the function call overhead > would be noticeable (I say this from having tested it). > > I'd like to hear details of what the actual problems are, so that we can > fix things rather than trying to hide them. I'm not going to be able to > work on anything like this for a little while (partly because of a > commitment to get some other code finished urgently), but we should fix > any difficulties.
we're using the str operation in various places. The default unicode --> str encoding is ASCII and that now gets used whereas before utf8 str --> str was a no-op. We're not using binary data merely what was implicit in the idea of char fields. If Django had added unichar fields that would have allowed both kinds of field to be used and kept backward compatibility for those who need it. I'm advised that it's impossible to change the default encoding (it's done in site.py, but I was warned against messing with it by people on the Python development team). One way round my current problems would be to override the unicode type being used to allow a django unicode-->str encoding to be specified, but probably that's not feasible either as it seems everyone just uses unicode without regard to the intended final use. The suggestion that we unpatch a single back end is probably doable, but we'll have more and more problems as time goes on. > > I'm not going to be too surprised to hear that it's something like > trying to use binary-like data in text fields -- getting a proper binary > field and, most importantly, getting transparent transmission to and > from the database in play is a pretty big priority once I have time. > It's not completely trivial, but, again, a clear description of the > problems you are having might help guide the design. That will, in > effect, provide a way to have deliberately unencoded data in both a > designated binary field and also available for any custom field types > and should solve some problems I suspect exist. > > Regards, > Malcolm > > -- Robin Becker --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
