>This is not magic. "print" looks for an "encoding" attribute on the file
>it is printing to. This is the terminal encoding for sys.stdout and None
>for other files.

I'll correct you:

"print" looks for an "encoding" attribute on the file it is printing to. This is the terminal encoding for sys.stdout *if sys.stdout is a terminal* and None when sys.stdout is not a terminal.

After all, the bug reported is that *the same program* behaved different when used standalone than when piped to less:

$ python -c "import sys; print sys.stdout.encoding" 
UTF-8
$ python -c "import sys; print sys.stdout.encoding" | cat
None

If you say that this is intended, not a bug, that an external process is altering the behavior of a python program, I'd just leave it written to warn other naive people like myself, that thinks that an external program should not influence python behavior (with *the same environment*):

$ locale
LANG=es_ES.UTF-8
LC_CTYPE="es_ES.UTF-8"
LC_NUMERIC="es_ES.UTF-8"
LC_TIME="es_ES.UTF-8"
LC_COLLATE="es_ES.UTF-8"
LC_MONETARY="es_ES.UTF-8"
LC_MESSAGES="es_ES.UTF-8"
LC_PAPER="es_ES.UTF-8"
LC_NAME="es_ES.UTF-8"
LC_ADDRESS="es_ES.UTF-8"
LC_TELEPHONE="es_ES.UTF-8"
LC_MEASUREMENT="es_ES.UTF-8"
LC_IDENTIFICATION="es_ES.UTF-8"
LC_ALL=es_ES.UTF-8

But I take it as a design flaw, and against all pythonic principles, probably coming from the fact that a lot of python developers/users are windows people that don't care about stdout at all.

IMO, the behavior should be either:
- use always None for sys.stdout
- use always LC_CTYPE or LANG for sys.stdout

I prefer the second one, as when I pipe stdout, after all, I expect it to be honoring my locale settings. Don't forget that the same person that types "|" after a call to python can type LC_ALL=blah before, while s/he can't sometimes modify the script because it is out of their permission set.

The implementation logic would be simpler too, I guess.

And more consistent with jython (it uses the second "always LC_CTYPE" solution). Not sure about iron-python or pypy.