On May 16, 8:49 pm, Gregor Horvath <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] schrieb: > >> 2) Create a way to internationalize the standard library (and possibly > >> the language keywords, too). Ideally, create a general standardized way > >> to internationalize code, possibly similiar to how people > >> internationalize strings today. > > > > Why? Or more acurately why before adopting the PEP? > > The library is very usable by non-english speakers as long as > > there is documentation in their native language. It would be > > Microsoft once translated their VBA to foreign languages. > I didn't use it because I was used to "English" code. > If I program in mixed cultural contexts I have to use to smallest > dominator. Mixing the symbols of the programming language is confusing.
Yup, I agree wholeheartedly. So do almost all the other people who have responded in this thread. In public code, open source code, code being worked on by people from different countries, English is almost always the best choice. Nothing in the PEP interferes with or prevents this. The PEP only allows non-ascii indentifiers, when they are appropriate: in code that is unlikely to be ever be touched by people who don't know that language. (Obviously any language feature can be misused but peer-pressure, documentation, and education have been very effective in preventing such misuse. There is no reason they shouldn't be effective here too.) And yes, some code will be developed in a single language enviroment and then be found to be useful to a wider audience. It's not the end of the world. It is no worse than when code written with a single language UI that is becomes public -- it will get fixed so that it meets the standards for a internationaly collaborative project. Seems to me that replacing identifiers with english ones is fairly trivial isn't it? One can identify identifiers by parsing the program and replacing them from a prepared table of replacements? This seems much easier than fixing comments and docstrings which need to be done by hand. But the comment/docstring problem exists now and has nothing to do with the PEP. > Long time ago at the age of 12 I learned programming using English > Computer books. Then there were no German books at all. It was not easy. > It would have been completely impossible if our schools system would not > have been wise enough to teach as English early. > > I think millions of people are handicapped because of this. > Any step to improve this, is a good step for all of us. In no doubt > there are a lot of talents wasted because of this wall. I agree that anyone who wants to be a programmer is well advised to learn English. I would also advise anyone who wants to be a programmer to go to college. But I have met very good programmers who were not college graduates and although I don't know any non- english speakers I am sure there are very good programers who don't know English. There is a big difference between encouraging someone to do something, and taking steps to make them do something. A lot of the english-only retoric in this thread seems very reminiscent of arguments a decade+ ago regarding wide characters and unicode, and other i18n support. "Computing is ascii-based, we don't need all this crap, and besides, it doubles the memory used by strings! English is good enough". Except of course that it wasn't. When technology demands that people adapt to it, it looses. When technology adapts to the needs of people, it wins. The fundamental question is whether languages designers, or the people writing the code, should be the ones to decide what language identifiers are most appropriate for their program. Do language designers, all of whom are English speakers, have the wisdom to decide for programmers all over the world, and for years to come, that they must learn English to use Python effectively? And if they do, will the people affected agree, or will they choose a different language? -- http://mail.python.org/mailman/listinfo/python-list
