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

"Martin v. Löwis" martin at v.loewis.de
Tue Oct 25 23:55:27 CEST 2005

Josiah Carlson wrote:
> And how users could say, "name error? But I typed in window.draw(PEN) as
> I was told to, and it didn't work!"

Ah, so the "serious issues" you are talking about are not security 
issues, but usability issues.

I don't think extending the range of acceptable characters will
cause any additional confusion. Users are already getting "surprising"
NameErrors/AttributeErrors in the following cases:
- they just misspell the identifier, and then, when the error message
   is printed, fail to recognize the difference, as they read over the
   typo just like they read over it when mistyping it in the first place.

- they run into confusions with different things having the same names
   in different contexts. For example, they wonder why they get TypeError
   for passing the wrong number of arguments to a function, when the
   call matches exactly what the source code in front of them tells
   them - only that they were calling a different function which just
   happened to have the same name.

In the light of these common mistakes, your example with an identifier
named PEN, where the "P" might be a cyrillic letter or the E a greek one
is just made up: For window.draw, people will readily understand that
they are supposed to use Latin letters. More generally, they will know
what script to use just from looking at the identifier.

> Identically drawn glyphs are a problem, and pretending that they aren't
> a problem, doesn't make it so.  Right now, all possible name glyphs are
> visually distinct

Not at all: Just compare Fool and Foo1 (and perhaps FooI)

In the font in which I'm typing this, these are slightly different - but
there are fonts in which the difference is really difficult to

> Speaking of which, would
> we then be offering support for arabic/indic numeric literals, and/or
> support it in int()/float()?

No. None of the Arabic users have ever requested such a feature, so
it would be stupid to provide it. We provide extended identifiers not
for the fun of it, but because users are requesting them.


More information about the Python-Dev mailing list