Tkinter wart: returned texts are sometimes strings, sometime Unicode strings

[Martin v. Löwis]

Eric Brunel <eric.brunel at pragmadev.com> writes:

> Sorry, but I don't think there are "applications that work for
> English": every application may be used by people whose native
> language is not english and who have funny characters directly on
> their keyboard that they are used to type quite often. 

This is certainly not the case. I believe a significant number of
Tkinter applications is used by only a few people, all of which speak
only a single language, and can only type ASCII at their keyboards.

> Getting a UnicodeError or some even stranger behaviour just because
> they typed one of these really does not seem to be a good idea.

Indeed, that's the reason for returning ASCII when possible: Too many
existing applications would have gotten UnicodeErrors otherwise.

> And in fact, I don't see even the point in returning a string if the
> text contains only plain ASCII: since Python default encoding *is*
> plain ASCII, what would have been the problem if the text returned was
> also a Unicode string?

There might be API which you cannot pass Unicode objects to. There
certainly was when Unicode support was added to _tkinter. In
particular, libraries that dispatch based on the data type will fail.

> I'd really like to have opinions from other people who use Tkinter and
> whose native language is not english. But IMHO, this would have been a
> far better idea, at least until Unicode strings can be manipulated
> exactly the same way plain strings are, which is not exactly the case
> today.

Can you elaborate? What operations are available on strings but not on
Unicode objects?

Regards,
Martin