Re: PEP 3131: Supporting Non-ASCII Identifiers

On Wed, 16 May 2007 16:29:27 +0200, Neil Hodgson <nyamatongwe+thunder@xxxxxxxxx> wrote:

Eric Brunel:

Have you ever tried to enter anything more than 2 or 3 characters like that?

No, only for examples. Lengthy texts are either already available digitally or are entered by someone skilled in the language.

> I did. It just takes ages. Come on: are you really serious about
entering *identifiers* in a *program* this way?

Are you really serious about entry of identifiers in another language being a problem?

Yes.

Most of the time your identifiers will be available by selection from an autocompletion list or through cut and paste.

Auto-completion lists have always caused me more disturbance than help. Since - AFAIK - you have to type some characters before they can be of any help, I don't think they can help much here. I also did have to copy/paste identifiers to program (because of a broken keyboard, IIRC), and found it extremely difficult to handle. Constant movements to get every identifier - either by keyboard or with the mouse - are not only unnecessary, but also completely breaks my concentration. Programming this way takes me 4 or 5 times longer than being able to type characters directly.

Less commonly, you'll know what they sound like.

Highly improbable in the general context. If I stumble on a source code in Chinese, Russian or Hebrew, I wouldn't be able to figure out a single sound.

Even more rarely you'll only have a printed document.

I wonder how that could be of any help.

Each of these can be handled reasonably considering their frequency of occurrence. I have never learned Japanese but have had to deal with Japanese text at a couple of jobs and it isn't that big of a problem. Its certainly not "virtually impossible" nor is there "absolutely no way of entering the word" (売り場). I think you should moderate your exaggerations.

I do admit it was a bit exaggerated: there actually are ways. You know it, and I know it. But what about the average guy, not knowing anything about Japanese, kanji, radicals and stroke counts? How will he manage to enter these funny-looking characters, perhaps not even knowing it's Japanese? And does he have to learn a new input method each time he stumbles across identifiers written in a character set he doesn't know? And even if he finds a way, the chances are that it will be terribly inefficient. Having to pay attention on how you can type the things you want is a really big problem when it comes to programming: you have a lot of other things to think about.
--
python -c "print ''.join([chr(154 - ord(c)) for c in 'U(17zX(%,5.zmz5(17l8(%,5.Z*(93-965$l7+-'])"
.

Relevant Pages

  • Re: Attention: European C/C++/C#/Java Programmers-Call for Input
    ... For any language using a Latin ... Look at existing tools and source code that supports UTF-8, and see how it can make your work easier and give a result that users might actually be able to *use*. ... But you'll find something that does a reasonable job and *will* work perfectly for most programmers who stick to ASCII identifiers. ... A related problem is if you are making identifiers case-insensitive - it's hard to figure out cases for non-ASCII characters. ...
    (comp.arch.embedded)
  • Re: Characters not being displayed when language settings are changed.
    ... As for the original question - if changing the language for non-unicode programs affects the way you see things, the program you're using must be a non-Unicode program. ... As such it will be using a code page to display non-ascii characters, and changing the language will have changed the code page in use - I think! ... But I think that MS Mincho is installed with Office/Windows by default because there are certain characters in that font that Word uses even when you think you're entering something in the Default Paragraph Font. ... Japanese IME? ...
    (microsoft.public.word.docmanagement)
  • Re: PEP 3131: Supporting Non-ASCII Identifiers - ambiguity issues
    ... two characters which look the same. ... The latter is a real problem in a language like Python with implicit ... This limits mixing of scripts ... We have to have visually unique identifiers. ...
    (comp.lang.python)
  • Re: PEP 3131: Supporting Non-ASCII Identifiers
    ... identifiers in Python. ... The diatribe about cross language understanding of Python code is IMHO ... Not providing an explicit listing of allowed characters is inexcusable ... categories uppercase letters, lowercase letters, titlecase ...
    (comp.lang.python)
  • Re: Question on Multiple language support
    ... I am getting started on multiple language support with MFC and VC++ ... DLLs in various languages incuding Japanese. ... under Win2000 the Japanese characters won't be displayed ... Depending on how things were installed, the default font may not have the characters ...
    (microsoft.public.vc.mfc)
Loading