On 5/25/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On 5/25/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> > I agree that saying "Japanese identifiers are OK from now on" still > > shouldn't turn on Cyrillic identifiers. I think the current > > alternative boils down to some variant of > > where allowedchars.txt would look something like > > 0780..07B1 ; Thaana > > or > > 10000..100FA ; Linear_B plus some blanks I was too lazy to exclude > I still think such a command-line switch (or switches) is the wrong > approach. What if I have *one* module that uses Cyrillic legitimately. > A command-line switch would enable Cyrillic in *all* modules. Yes. And that is the desired outcome for a student situation. > ... Auditing code using a separate tool can ... Large organizations can do whatever they need to, including an automated transliteration before import. The concern is for relatively small groups, who don't have huge processes in place. (1) A new student shouldn't need to learn about import flags just to use native characters. Giving such fine-grained control as an advanced option is OK, but it shouldn't be the *only* way to say "ASCII + characters I use when reading or writing." (2) Someone downloading source code (not binary, source code) shouldn't have to remember to run that code through an external tool just to see if it uses unexpected characters (and might be saying something very different from what she expected). Note that this applies even to people who do want the extended identifiers; wanting to write Han Chinese characters does not imply wanting to accept Greek Coptic characters. -jJ _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
