John Cowan wrote:
Tobia Conforto scripsit:
This is more or less how other languages, such as Python, solved
the issue. Two kinds of strings, byte and unicode, and
overloading a few string operations to have a slightly different
meaning when called on either, computing byte length vs. character
length.
And Python 3.0 is ditching this solution in favor of byte strings
and Unicode strings instead, because it's unworkable in the long
run. In Py3k, you'll write b"..." for a byte string and "..." for a
Unicode string; u"..." will be a deprecated synonym. Python 2.6,
the bridge release, will support b"..." to assist transition.
So they're ditching {"byte", u"unicode"} strings in favor of {b"byte",
"unicode"} ones? What are they ditching exactly? It seems to me
they're just switching the default.
Graham Fawcett wrote:
I agree 100% that Unicode support should be core. And on that note
I'll stop muddying the waters and give my +1 to copying utf8 into
the core and adding a suite of byte- functions.
+1 best solution overall
Tobia
_______________________________________________
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users
