Aren't there some connection parameters from DB-API that specify the current encodings accepted? Perhaps SQLObject can do (approximate guess):
str = ustr.encode(self.c.encoding) That's going to cause big fudgeups when trying to insert binary data though. I have a personal vendetta against strings in Python though. I'm of the believe that Python shouldn't care about character encoding, or even try to detect it, unless a specific encoding-related operation is performed on the string (such as .lower()). Python attempts to auto-coerce strings between encodings far too often. I think the solution for this is to determine exactly how unstable psycopg2 is, and whether we can use SQLObject with it. SQLObject has only got to use a limited set of psycopg2's features, and it could well be that those features are stable. If so, we can recommend that as the DB-API driver. It'll probably unnerve people who like to stick to packages provided by their distro (like me), but everyone's going to need to be using non-distro sources for TG anyway so one more driver isn't going to hurt. Provided that it depends on PG C libs that ship with stable distributions, however. -Rob Gerhard Häring wrote: > So either TurboGears needs to make sure it's only sending bytestrings to > SQLObject, or SQLObject needs to have a way to set a client encoding and > use this to convert Unicode strings to bytestrings before sending the > queries to the DB-API module. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears -~----------~----~----~----~------~----~------~--~---
