The builtin compile() signature looks like:

  compile(string, filename, kind[, flags[, dont_inherit]])

The string parameter can be either StringType or
UnicodeType, but the filename parameter will be
converted to StringType, so if there are non-ascii
characters in the unicode object passed, it raises
UnicodeEncodeError.

This can be an issue on filesystems having utf-8
filenames, or when using non-English names for the
backtrace beautification.

The attached file contains a unit test that will
succeed when the bug is resolved. I saw the error in
2.3 and 2.4, maybe it is there for all releases?

Logged In: YES 
user_id=1188172

Should compile() use the Py_FileSystemEncoding?

Logged In: YES 
user_id=21627

Why couldn't co_filename just be the Unicode string? I think
one would have to change:
- code_repr, to convert the filename into a byte string
(preferably using 'ascii', 'replace')
- tb_printinternal (not sure what to do here)
- code_new, to accept either strings or unicode strings
- builtin_compile, which probably indeed needs to convert
the string using the file system encoding, and then patch
the resulting code object to point to the unicode object
originally passed (unless we can accept more pythonrun
functions).

Logged In: YES 
user_id=849994

Sounds sound. :)

Logged In: YES 
user_id=156682

loewis, I confess I could not understand a word.

But as I see, it would have some advantages to have a
completely unicode internal filename representation on
systems having multiple filesystems mounted with different
encodings, or systems having simply utf-8 filesystems (no
'ascii', 'replace' for allowing two filenames differing only
in accents).

I agree with Joel Spolsky
(http://www.joelonsoftware.com/articles/Unicode.html), and I
think that if choosing unicode could be easier in a
language, than most of l10n problems would be solved. I
understand, that coding unicode in C is a pain.

Imagine - theoretically - if a literal like "hello" would
automatically mean a unicode object in python, and you had
to write s"hello" to make a literal string object encoded in
a way some enviromental settings (or maybe the PEP 0263
header of the specific source file?) determine, so you have
control on what happens.

Imagine the case when there is a latin1 and a utf-8
partition mounted, and the console is latin2! Life would be
much, much easier for a non-American programmer if she had
to be aware from the first moment, that she is in an
international environment.

Confirmed on trunk.

I don't think this will be dealt with in the 2.x series.  Python 3
already has support for Unicode file names, so it's out of date there.