[Python-Dev] Divorcing str and unicode (no more implicitconversions). (original) (raw)

"Martin v. Löwis" martin at v.loewis.de
Wed Oct 26 08:09:33 CEST 2005

Josiah Carlson wrote:

In this case it's not just a misreading, the characters look identical! When is an 'E' not an 'E'? When it is an Epsilon or Ie. Saying what characters will or will not be used as identifiers, when those characters are keys on a keyboard of a specific type, is pretty presumptuous.

Why is that rude and disrespectful? I'm certainly respecting developers who want to use their scripts for identifiers, or else I would not have suggested that they could do so.

However, from the experience with my own language, and the three or so foreign languages I know, I can tell you that people would normally don't mix identifiers of different scripts.

Sure, that example was made up, but there are words which have been stolen from various languages by english, and you are discounting the case of single-letter temporary variables. Saying what will and won't happen over the course of using unicode identifiers is quite the prediction.

Sure, people can make mistakes. They get an error, and then will need to find the cause of the problem. Sometimes, this will be easy, and sometimes, it will not.

Indeed, they are similar, but different in my font as well. The trick is that the glyphs are not different in the case of certain greek or cyrillic letters. They don't just /look/ similar they /are identical/.

This string: "EΕ" is the LATIN CAPITAL LETTER E, followed by the GREEK CAPITAL LETTER EPSILON. In the font my email composer uses, the E is slightly larger than the Epsilon - so there /is/ a visual difference.

But even if there isn't: if this was a frequent problem, the name error could include an alternative representation (say, with Unicode ordinals for non-ASCII characters) which would give an easy visual clue.

I still doubt that this is a frequent problem, and I don't see any better grounds for claiming that it is than for claiming that it is not.

Regards, Martin

More information about the Python-Dev mailing list