Phillip J. Eby wrote:
At 09:11 AM 8/22/2005 -1000, Brian Kirsch wrote:
The two suggestions currently floating around other than UString are:
1. Unicode
2. Text
Unicode is nice cause it is straight and to the point and will be
easily understandable by developers familiar with what Unicode is.
But also has the flipside that Python developers who know what Unicode
is may go looking for a "String" type.
The flipside argument could be made that if the Python developer sees
Text he or she will think it can be used to store ASCII which is not the
case. The Bytes type is there to solve the need to store developer level
non-displayable strings. Chandler is a Unicode app and should only deal
with ASCII at I/O conversion points and for low level developer tasks.
Text on the other hand is a bit simpler for the beginning developer
to understand but is not descriptive on the types it accepts.
For example, passing a Python str to a proposed Text type will raise
an error on Repository commit since the type only accepts unicode.
This would be just as confusing with the Unicode name, since Python
accepts pure ASCII strings wherever the unicode type is accepted.
Regardless of which name is used the type should probably accept pure
ASCII strings anyway.
I am fine with a convience constructor that takes an ASCII value and
converts it to unicode internally. However, the UString or Unicode or
Text or whatever it ends up being called should always store and return
text as unicode.
So the question is do we go with a descriptive (Unicode) or
simplistic (Text) approach.
I would say the question is whether we go with a name that defines the
purpose of the value (Text) or describes an implementation detail
(Unicode). :)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
