It seemed to me that this sentence For many types, this function makes an attempt to return a string that would yield an object with the same value when passed to eval().
might mean that the encoding setting of the source file might influence how repr represented the contents of the string. Nothing to do with Unicode. If a source file could have a declared encoding of, say, cp932 via the # coding comment, I thought there was a chance that eval would respond to that, too. Diez B. Roggisch wrote: > JKPeck wrote: > > > Thanks for the quick answer. I thought repr was involved here, but > > when I use repr explicitly I get a notation where the backslashes are > > escaped. I also though that with the encoding explictily declared in > > the source, that repr would take that into account and use the > > character form, but obviously it doesn't. > > The encoding in the source has nothing to do with that. How should an > encoding (and possibly a gazillion different ones in gazillion other > sourcefiles of yours) influence the list repr code? > > The encoding in the source-file is solely used to correctly parse unicode > literals, as these need a specific encoding to be generated from the > byte-string they are in the sourcecode. > > Diez -- http://mail.python.org/mailman/listinfo/python-list