On Thu, Oct 14, 2004 at 04:10:59PM -0700, Jim Dukarm wrote:
> I was expecting to start running into places (esp. forms) where
> Quixote would have to be hacked or bypassed [to support Unicode],
> but now I will immediately start using qx 2.0.

Well, I hope it makes life easier.  The idea of the design is that
it is okay to use either str or unicode objects anywhere.  Quixote
should play nicely with either.  str objects will not be needlessly
promoted to unicode and unicode objects will not be forced into str
objects.  As far as Quixote is concerned,  __str__ methods can
return either type.  Obviously the application can still get itself
into trouble, e.g.:

    >>> '\xff' + u'foo'
    Traceback (most recent call last):
      File "", line 1, in ?
    UnicodeDecodeError: 'ascii' codec can't decode byte 0xff in
    position 0: ordinal not in range(128)

Quixote can't do anything about that.  If you only use ASCII
characters inside str objects and use unicode for the result then
everything should work fine.  There's no need to banish str objects
completely.

If the result of a traversal ends up containing unicode then it will
be encoded at the last possible moment (i.e. right before it is
written to the client).  I consider encoding to be a form of
pickling for unicode objects.

Please let me know how things go.  I'd like to fix major design
flaws before hitting 2.0. :-)

  Neil