[Python-3000] Support for PEP 3131

Stephen J. Turnbull stephen at xemacs.org
Fri May 25 14:53:10 CEST 2007

Guido van Rossum writes:

 > If there's a security argument to be made for restricting the alphabet
 > used by code contributions (even by co-workers at the same company), I
 > don't see why ASCII-only projects should have it easier than projects
 > in other cultures.

(1) Because all projects are currently ASCII-only.  I don't hear any
complaints from projects currently using non-ASCII identifiers<wink>,
and there will be few for many months.  The scaling argument gets a
similar response.  I.e., "it won't hurt (not much nor soon)".
N.B. Consistent with my Emacs Lisp experience.  What is Common Lisp
and/or Java experience?

I recall Alex Martelli's discussion of even allowing non-English
comments during PEP 263.  Many shops will resist non-ASCII identifiers
in published or purchased modules, even in the European community, I
would think.  Jamie Zawinski has an amusing anecdote about the great
profanity purge at Netscape; I bet that kind of boss would not be at
all happy about the idea of swear words he can't read.

The only thing that really worries me here is Martin's "people will
try it and think it's unimplemented" argument (avoidably delaying
diffusion of -U unicode), but I think a

SyntaxError: 'non-ASCII identifier: invalid unless enabled with the -U option'

would alleviate that.

(2) Because due to the scaling argument and reduction of fear of the
unknown, as well as development of the collateral tools, changing the
default from 'ascii' to 'unicode' will be very natural within a few

I'm sympathetic to the argument that it's even more natural to make
the default unicode _now_ (ie, for the release of Python 3 which is
still well in the future) and let the conservatives use '-U ascii',
but (a) we have no experience with such a Python, and (b) we don't
have any of the tools yet, and I don't see why we would trust them to
do a good job without the experience.  At least for the "lookalike
glyphs" issue the devil is very much in the details.  Trial and error
stuff, to some extent.

More information about the Python-3000 mailing list