Re: [SQLObject] SQLObject Cookbook: persons & roles, recipes 01 and 02

[Ian B. <ia...@co...>]

Oleg Broytmann wrote:
> On Wed, Mar 16, 2005 at 03:10:02PM -0300, Carlos Ribeiro wrote:
> 
>>>   My thought was exactly opposite - always use StringCol in the
>>>cookbook.
>>
>>Debatable at best... I read somewhere that the plan for Python is to
>>drop the unicode/string difference and have only one kind of
>>'character string', that will be unicode based. A new bytes/buffer
>>type will be added to store sequences of bytes transparently (that's
>>one of the uses of strings today).
> 
> 
>    Then we'll drop UnicodeString, and StrinCol will grow a
> charset/encoding parameter! (-:

Ultimately I think StringCol should support unicode, relying on the 
database to natively store unicode -- that's contingent both on database 
unicode support, driver unicode support, and moving to DB-API 
parameters.  UnicodeCol is for supporting Python unicode strings when 
the database does not (or when any piece of the chain does not).  Though 
I think if StringCol becomes more capable, UnicodeCol will seem 
redundant and a hinderance to database portability -- for those 
databases that don't support Unicode (for instance, maybe SQLite will 
stick with the columns-as-bytes perspective) it would be most convenient 
to indicate a default encoding for the connection (e.g., 
'sqlite:/file?encoding=UTF-8'), and the rest of SQLObject can pretend 
the database is unicode-aware.

-- 
Ian Bicking  /  ia...@co...  /  http://blog.ianbicking.org