Florent Guillaume wrote at 2005-7-4 15:01 +0200:
>Dieter Maurer <[EMAIL PROTECTED]> wrote:
>> Florent Guillaume wrote at 2005-7-1 20:43 +0200:
>> > ...
>> >The problem is on import, you don't really know if a non-ascii string
>> >should be stored as unicode or as an encoded str. And the software
>> >may break if it gets something it doesn't expect...
>> That's why the whole Python world including Zope (it does with Zope 3)
>> and CMF should follow Java and require "for text always use Unicode".
>> And for non-text, CMFSetup should use a specialize "binary" type.
>Again, I couldn't agree more. My problem here is backward compatibility.
As soon as you fiddle around with encodings, you must know
what is text and what binary data.
Following the "explicit is better than implicit" principle,
the introduction of a new type (or maybe even better two) seems appropriate
-- with a reasonable default for backward compatibility.
E.g. we assume all Python strings to refer to "text" (i.e. unicode
in some encoding).
Zope-CMF maillist - Zope-CMF@lists.zope.org
See http://collector.zope.org/CMF for bug reports and feature requests