Em Quarta 19 Abril 2006 06:03, Gerhard Häring escreveu: > Which means that you cannot use Unicode strings as parameters to > SQLObject, because then *SQLObject* creates queries as Unicode strings.
Isn't this correct? After all, you're saying that you want unicode. If you send non-unicode strings you get non-unicode strings with SQLObject and it also works. > 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. I believe that it is the developer who needs to do that configuration. It should not be magically done. TurboGears need to work with anything it gets and is legal Python. What one really needs to do is to be coherent with all strings and documents (kid templates, for example): use only one encoding and stick to it and declare it everywhere you can so that there's no guessing. There are some stuff on the wiki about I18N that also covers this -- specially the sitecustomize.py tip that can also be coded in your start-<project>.py -- and might help. I believe that TG's behavior is correct in respecting the encoding and not doing any magic with strings. It is really hard to setup your database environment (that might be working with several other apps at the same time) and then have an inconsistent behaviour using only SQLObject or TG + SQLObject (and also remember that we'll have SQLAlchemy support real soon, so ...). -- Jorge Godoy <[EMAIL PROTECTED]> --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
