[Python-3000] Support for PEP 3131
showell30 at yahoo.com
Sat May 26 02:42:18 CEST 2007
--- Guido van Rossum <guido at python.org> wrote:
> On 5/25/07, Jim Jewett <jimjjewett at gmail.com> wrote:
> > On 5/24/07, Guido van Rossum <guido at python.org>
> > > It doesn't look like any kind of global flag
> passed to the interpreter
> > > would scale -- once I am using a known trusted
> contribution that uses
> > > a different character set than mine, I would
> have to change the global
> > > setting to be more lenient, and the leniency
> would affect all code I'm
> > > using.
> > Are you still thinking about the single on/off
> > 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
> > python -idchars allowedchars.txt
> > where allowedchars.txt would look something like
> > 0780..07B1 ; Thaana
> > or
> > 10000..100FA ; Linear_B plus some blanks I was
> too lazy to exclude
> > (These lines are based on the unicode Scripts.txt,
> and use character
> > ranges instead of script names so that you can
> exclude certain symbols
> > if you want to.)
> 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*
I agreed with you at first that once you allow
Cyrillic code from your good, trusted buddy that codes
in Cyrillic, you essentially open the door for all bad
people that code in Cyrillic, so enabling/requiring a
flag that trusts/distrusts Cyrillic code is basically
an exercise in futility.
But why couldn't there be a mechanism to accept only
individual non-ascii modules as trusted modules?
Expecting? Get great news right away with email Auto-Check.
Try the Yahoo! Mail Beta.
More information about the Python-3000