Em Quarta 19 Abril 2006 06:31, Robin Haswell escreveu:
> 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)
At least there's none for psycopg2:
The full list of available parameters is:
- dbname -- database name (only in 'dsn')
- database -- database name (only as keyword argument)
- host -- host address (defaults to UNIX socket if not provided)
- port -- port number (defaults to 5432 if not provided)
- user -- user name used to authenticate
- password -- password used to authenticate
- sslmode -- SSL mode (see PostgreSQL documentation)
> 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
For binary data there are binary types:
(http://sqlobject.org/SQLObject.html)
BLOBCol:
A column for binary data. Presently works only with MySQL, PostgreSQL and
SQLite backends.
I believe that in Python 2.5 everything will be handled as Unicode, so there
won't be differences in string types anymore. Using Unicode today is a safe
bet.
> 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 agree. And this will be solved when there will be just one string type
> I think the solution for this is to determine exactly how unstable
> psycopg2 is, and whether we can use SQLObject with it. SQLObject has
I'm using psycopg2 for months now. Everything setup as UTF-8. After some
problems and fixes in TG's code (there were parts that tried converting
unicode to str) I don't have problems anymore.
> 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.
I am against requiring that binary drivers be recompiled. Specially on
servers where I am against having things that aren't needed for the server
configuration. If everytime I have to update something I have to install and
remove the whole C development environmento + database includes + ... then
I'd look for something else.
I believe the solution is what I told Gerhard on the other message: choosing
one and only one encoding per project and sticking to it. If you need to be
compatible with multiple languages, then utf-8 is it, otherwise you're free
to decide. And Python will have only unicode strings in the future...
--
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
-~----------~----~----~----~------~----~------~--~---
