Unicode capability expansion

[Kee Nethery]

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.