I like what Python decided to do with Unicode. There is no more ascii
text in Python 3.x, all text is unicode. Seems like the best solution
to me. No deciding whether this or that function supports unicode,
they all do. The only difference is that you need a new term to stand
in for a byte in a data stream, for example
select byte 2 to 7 of thestuff
vs
select char 2 to 7 of thestuff
byte 2 to 7 would give you 6 bytes of data.
char 2 to 7 would give you 6 or more bytes because you don't know (or
care) how the characters are represented, could be UTF-8, UTF-16, etc.
If you deal with characters and words and lines, you are always
dealing with complete unicode characters.
Just my 2 cents.
Kee Nethery
On Jul 17, 2009, at 8:10 AM, Richmond Mathewson wrote:
Having "fiddled around" with unicode rcecently it has
become clear (unless I have missed something) that
Revolution can only cope with characters from the
Basic Multilingual Plane - i.e. chars up to 65535 (hex FFFF).
This is a real limitation that stands in the way of a lot of
programming possibilities with Revolution.
I am unaware of how most comparable RADS handle
unicode (Supercard simply doesn't).
I would urge the expansion of unicode capabilities
as a top priority.
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
