[Python-Dev] Divorcing str and unicode (no more implicitconversions). (original) (raw)
"Martin v. Löwis" martin at v.loewis.de
Tue Oct 25 23:55:27 CEST 2005
- Previous message: [Python-Dev] Divorcing str and unicode (no more implicitconversions).
- Next message: [Python-Dev] Divorcing str and unicode (no more implicitconversions).
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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 recognize.
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.
Regards, Martin
- Previous message: [Python-Dev] Divorcing str and unicode (no more implicitconversions).
- Next message: [Python-Dev] Divorcing str and unicode (no more implicitconversions).
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]