PEP 3131: Supporting Non-ASCII Identifiers

Stefan Behnel stefan.behnel-n05pAM at web.de
Tue May 15 11:41:25 EDT 2007


Paul Boddie wrote:
> On 15 May, 16:39, Stefan Behnel <stefan.behnel-n05... at web.de> wrote:
>> It's difficult to extract this analysis from Java. Most people I know from the
>> Java world do not use this feature as it is error prone. Java does not have
>> support for *explicit* source encodings, i.e. the local environment settings
>> win. This is bound to fail e.g. on a latin-1 system where I would like to work
>> with UTF-8 files (which tend to work better on the Unix build server, etc.)
> 
> Here's a useful link on this topic:
> 
> http://www.jorendorff.com/articles/unicode/java.html

This is what I meant (quote from your link):

"""
When you compile this program with the command javac Hallo.java, the compiler
does not know the encoding of the source file. Therefore it uses your
platform's default encoding. You might wish to tell javac which encoding to
use explicitly, instead. Use the -encoding option to do this: javac -encoding
Latin-1 Hallo.java . If you do not specify the right encoding, javac will be
confused and may or may not generate a lot of syntax errors as a result.
"""

>From a Python perspective, I would rather call this behaviour broken. Do I
really have to pass the encoding as a command line option to the compiler?

I find Python's source encoding much cleaner here, and even more so when the
default encoding becomes UTF-8.

Stefan



More information about the Python-list mailing list