[Python-Dev] Re: PEP 263 - Defining Python Source Code Encodings

[Guido van Rossum]

> > and tying such a proposal to this PEP is definitely the wrong thing.
> 
> Expected and understood.  I merely hope that this PEP's "concept" will
> not later be quoted as rigid.  Going back from Unicode through ASCII may
> be today's way for implementing PEP 263, but not necessarily the only one.

Sure.

> > Allowing non-ASCII identifiers may eventually happen, but there are
> > lots of reasons why it's a bad idea (such as source code portability),
> 
> If Unicode letters get eventually accepted in Python identifiers, I do not
> much see what portability problems it would create.  I mean, not more than
> with generators, or any other Python feature.  It's forward compatible.

Well, for one, not everybody has an easy way to edit Unicode files.  I
expect I'd have to spend half a day downloading new stuff before I
could.

There's an issue with 8-bit encodings that is hopefully resolved by
the encoding cookie proposed by this PEP -- but we'll have to see how
well the PEP gets adapted.  Not only Python itself needs to recognize
these cookies -- also all tools that scan Python sources.
(E.g. pyclbr.py and tokenize.py in the standard library.)

> Unless you mean that by encouraging non-English writings, _this_ creates
> a threat to portability, where English is the planetary computer language
> for exchanges.  The point is that many Python programs, contrarily to
> the Python distribution itself, are not aiming the planet, and for some
> communities or teams, would be more useful and comfortable if not English.

This is exactly what the Chinese are already doing.  I'm just worried
that sooner or later they'll write someting that's useful outside
China.  I hope that English will remain the language for libraries
shared within the Python community at large.

> Each thing in its proper time, of course.  Just let's keep the doors opened.

Always.

--Guido van Rossum (home page: http://www.python.org/~guido/)