[Python-3000] Support for PEP 3131 (original) (raw)

James Y Knight foom at fuhm.net
Thu May 24 23:47:45 CEST 2007

On May 24, 2007, at 5:04 PM, Ka-Ping Yee wrote:

(1) By default, python allows only ASCII. (2) Additional characters are permitted if they appear in a table named on the command line. +1! This is a fine solution. It is better than the "python -U" option I proposed -- it has all the advantages of that proposal, plus: - The identifier character set won't spontaneously change when one upgrades to a new version of Python, even for users of non-ASCII identifiers.

FUD. Already won't, unicode explicitly makes that promise. They can
add characters, but not remove them.

- Having to specify the table of acceptable characters demonstrates at least some knowledge of the character set one is using.

This is a negative. Why should I have to show knowledge of the
character set I'm using to type the characters?

- It provides the flexibility for different communities to to adopt identifier conventions that suit their preferred tradeoff of risk vs. expressiveness.

Also a negative. Now, if I want to run the modules from multiple
communities I need to figure out how to merge the tables they have to
separately distribute with their modules.

Jim's proposal appears to be the best path to making everyone happy.

Nope. It does nobody any good. It may make people who fear non-ascii
code happy, but only because it totally castrates this feature for
people who do want to use non-ascii identifiers.

It really seems to me people are spewing a lot of FUD here. Rejecting
certain characters when loading a file is simply not necessary.

Either:

a) you trust that the author of the file has authored it correctly,
in which case it doesn't matter one bit what character set they used.
Restricting the charset at import time is just something to get in
your way with no actual value.

b) you don't trust the code, and want to inspect it.

Okay, in this case you actually have to inspect the code --
checking the character set is an utterly useless thing to do by
itself. It tells you nothing useful.

While checking the code, you may want to have strange characters
outside your comfort range flagged for you. Either grep or editor
support are a simple enough solution for this. Or, let's say your
editor is unable to highlight suspicious characters, and you want to
find identifiers with strange characters, and not get tripped up on
comments. Fine, make a tool that uses the compiler.parser module to
iterate over identifiers in the source code.

Adding baroque command line options for users of other languages to
do some useless verification at import time is not an acceptable
answer. It'd be better to just reject the PEP entirely.

James

More information about the Python-3000 mailing list