When replacing sys.stdout, stderr and/or stdin with non-file, file-like objects in sitecustomize, and also having an environment that makes Python set the encoding of those streams, Python will crash. PyFile_SetEncoding() will be called after sys.stdout/stderr/stdin are replaced, passing the non-file objects.

Fix by not calling PyFile_SetEncoding() in these cases. I'm not entirely sure if we should warn or not; not setting encoding only for replaced streams may cause a disconnect between stdout and stderr that's hard to explain, when someone only replaces one of them (in sitecustomize.) Then again, not many people must be doing it, as it currently just crashes.

No idea how to test for this, from a unittest :P

I can think of a nasty way to test this, but it's not really worth it.  You'd need to 'install' your own sitecustomize.py by setting PYTHONPATH and spawning a python.  Ok, so it's not a real unit test, but it is a test. :-)

This looks like it will also crash (before and after the patch) if sys.std{in,out,err} are just deleted rather than replaced (pythonrun.c).  sysmodule.c looks fine.

I think this is fine for 2.5.1.

Forgot to mention that I agree about the warning.  If no one noticed so far, this is such an obscure case, it's not that important to warn.  Either way is fine with me.

Oh, for the record: I was unable to produce a crash by *deleting* sys.stdin/stdout/stderr (although it produced funny results. In particular when I adding a 'print' statement after the deletes, in my sitecustomize.py, to make sure it was getting run. Of course, the print never arrived ;-P)