[Python-3000] Support for PEP 3131
gproux+py3000 at gmail.com
Fri May 25 03:05:01 CEST 2007
There has been many proposals of flags around.
I don't even understand anymore which -U you are talking about now.
But let me add my own proposal for a flag. (just to confuse everybody
else a little more)
It is my understanding that the only remaining objection for unicode
in identifier is for claimed security issues. The most important
application of unicode in identifiers in my view would be to bring
back computer control to children (like in the OLPC project).
(Notwithstanding the fact that AFAIK we have yet to hear about big
security issues in Java/C# world that were caused by the ability to
use unicode chars).
So probably a good flag for security-minded people would be to have
like gcc a "pedantic" flag.
python -pedantic no_scary_chars_here.py
Regarding the the notion you should be able to give a single accepted
charset, the problem arises that restricting charsets on a global
scope (from a global command line flag or a site.py file) will prevent
me for example to freely mix English, French, Greek and Japanese in
the same large project and/or dynamically call on any .py with a
I also think one of the great aspect of python is the ability to
simply get embedded in other C/C++/etc. projects and as such we need
to give the interpreter-embedders the ablity to execute any script the
user will present them without restricting to any specific charset.
The additional burden that ascii loving people would like to impose on
the rest of the world through the usage of command line switches is
I would think that a better way to help everybody would be to:
1) have a default of not restricting identifiers charsets but...
2) enable various people (or security minded distributions) to have a
customized site.py or $HOME file that would spit warnings or raise
exceptions when opening up files that have identifiers that are not
pure ascii. Notice that having to verify that EACH and EVERY
identifier can be expressed in a specific charset is going to be an
expensive runtime cost.
A good middle-ground would be to have the main python distribution
come out with the site.py spitting warnings (and giving a quite
explanation of why the warning and how to disable it for yourself (not
globally) if you are REALLY REALLY sure).
It would be very interesting to enable the first time "interactive"
user to be able to disable the warning for *this* user for good from a
More information about the Python-3000