tkinter + unicode + bug or feature??

vincent wehren v.wehren at home.nl
Sat Jan 25 08:33:00 CET 2003


"Martin v. Löwis" <martin at v.loewis.de> schrieb im Newsbeitrag
news:b0t0qj$76g$05$1 at news.t-online.com...
> Bob van der Poel wrote:
> > BTW, I really think this is a bug. If you enter "ascii" text into the
> > entry box you get() returns a string, if you enter "extended ascii" you
> > get a unicode string. <..>
> > Well, yes. Being on the US-side (altho I do live in Canada and we're a
> > bit less centric in our thinking) I was just referring to a "normal"
> > encoding...whatever that is :)
>
> There is no such thing.
>
> > Yes, local.getlocale() works fine. Now, if I do use encode on these
> > strings, will I run into problems if the user's locale is not encodable
> > into 8bits. Or can that not happen?
>
> Depends on what you mean by "8bits". You might have meant to ask
>
> Q. Could it happen that the user enters characters that cannot be
> represented in the 'normal encoding'?
> A. Yes, this can happen. If you merely want to compare this to another
> byte string, you should decode that byte string to Unicode, and perform
> the comparison then.
>
> or you meant to ask
>
> Q. Could it happen that the encoding produces more than one byte per
> character.
> A. Yes, this can happen, but it is no problem.
>
> or you meant to ask
>
> Q. Will Python support 'normal encodings' that produce more than one
> byte per character out of the box?
> A. No, Python does not ship with any such codecs (*). You should install
> the JapaneseCodecs, KoreanCodecs, or ChineseCodecs package for that.

ChineseCodecs? Are those the ones the guys at BasisTech promised to the
Python community
(http://www.basistech.com/papers/chinese/python-zh-transcoding-iuc20-te2.pdf
)? Are they aleady available?

Vincent Wehren


>
> Regards,
> Martin
>
> (*) Except for UTF-8, UCS-2, UCS-4.
>






More information about the Python-list mailing list