Stefan Behnel a écrit : > Eric Brunel wrote: >> On Mon, 14 May 2007 11:00:29 +0200, Stefan Behnel >>> Any chance there are still kanji-enabled programmes around that were >>> not hit >>> by the bomb in this scenario? They might still be able to help you get >>> the >>> code "public". >> Contrarily to what one might think seeing the great achievements of >> open-source software, people willing to maintain public code and/or make >> it evolve seem to be quite rare. If you add burdens on such people - >> such as being able to read and write the language of the original code >> writer, or forcing them to request a translation or transliteration from >> someone else -, the chances are that they will become even rarer... > > Ok, but then maybe that code just will not become Open Source. There's a > million reasons code cannot be made Open Source, licensing being one, lack of > resources being another, bad implementation and lack of documentation being > important also. > > But that won't change by keeping Unicode characters out of source code.
Nope, but adding unicode glyphs support for identifiers will only make things worse, and we (free software authors/users/supporters) definitively *don't* need this. > Now that we're at it, badly named english identifiers chosen by non-english > native speakers, for example, are a sure way to keep people from understanding > the code and thus from being able to contribute resources. Broken English is certainly better than German or French or Italian when it comes to sharing code. > I'm far from saying that all code should start using non-ASCII characters. > There are *very* good reasons why a lot of projects are well off with ASCII > and should obey the good advice of sticking to plain ASCII. But those are > mainly projects that are developed in English and use English documentation, > so there is not much of a risk to stumble into problems anyway. > > I'm only saying that this shouldn't be a language restriction, as there > definitely *are* projects (I know some for my part) that can benefit from the > clarity of native language identifiers (just like English speaking projects > benefit from the English language). As far as I'm concerned, I find "frenglish" source code (code with identifiers in French) a total abomination. The fact is that all the language (keywords, builtins, stdlib) *is* in English. Unless you address that fact, your PEP is worthless (and even if you really plan to do something about this, I still find it a very bad idea for reasons already exposed). The fact is also that anyone at least half-serious wrt/ CS will learn technical English anyway. And, as other already pointed, learning technical English is certainly not the most difficult part when it comes to programming. > And yes, this includes spelling native > language identifiers in the native way to make them easy to read and fast to > grasp for those who maintain the code. Yes, fine. So we end up with a code that's a mix of English (keywords, builtins, stdlib, almost if not all third-part libs) and native language. So, while native speakers will still have to deal with English, non-native speakers won't be able to understand anything. Talk about a great idea... -- http://mail.python.org/mailman/listinfo/python-list
