[ZODB-Dev] OOBTree: Persistent Objects as keys

[Toby Dickenson]

>But regardless of ZOPE and BTrees, mixing unicode and plain strings
>is a fairly sure way of shooting yourself in the foot in many other
>ways. Why would you like to do that?

Its not *always* crazy.... Python goes to great lengths to assure that 
u'hello' and 'hello' are almost equivalent. They hash the same, compare the 
same, and can be written to files the same.

Even when dealing with non-ascii characters it is not always crazy. Note that 
an original design goal of the current Unicode Implementation was to allow 
character-encoding-aware code which freely mixes up the two types of string, 
and only deals with the encoding issue in a UnicodeError exception handler. 

(This is the approach taken by my patches for Unicode support in Zope.... 
Given a legacy database which uses non-unicode strings, and new code which 
wants to use unicode, there is no way around dealing with this difficult mix)

Mixing unicode and *non-ascii* strings can cause problems in some areas which 
are not aware of the potential for exceptions. BTrees are one such 
area.....

I wouldnt be arguing this one if BTrees always raised an exception at the 
first sign of danger, the same way Jim is proposing when mixing other types 
that do not have a strict ordering. The problem is that BTrees will happily 
allow you to mix these values, and allow the transaction to commit, but then 
raises exception very much later when accessing completely unrelated keys.


(I would also be moderately if we concluded that we couldnt get round 
this problem at BTree level, and application level type checking proved to be 
necessary.)