Chris Withers wrote:
Would anyone object if I removed the deletion of of sys.setdefaultencoding in site.py?
I'm guessing "yes!" so thought I'd state my reasons now:
This deletion appears to be pretty flimsy; reload(sys) and you have it back. Which is lucky, because I need it after it's been deleted...
Why? Well, because you can no longer put sitecustomize.py in a project-specific location (http://bugs.python.org/issue1734860) and because for some projects the only way I can deal with encoded strings sensibly is to use setdefaultencoding, in my case at the start of a script generated by zc.buildout's zc.recipe.egg (I *know* all the encodings in this project are utf-8, but I don't want to go playing whack-a-mole with whatever modules this rather large project uses that haven't been made properly unicode aware).
Yes, it needs to be used as early as possible, and the docs should say this, but deleting it seems to be petty in terms of stopping its use when sitecustomize.py is too early and too system-wide and spraying .decode('utf-8')'s all over a code base made up of a load of eggs managed by buildout simply isn't feasible...
Let's look at this from another angle: sys.setdefaultencoding() is only made available for use in site.py. This is documented and by design (since a site may want to set the default encoding based on the locale or to "utf-8").
If you use it anywhere else, you're on your own. Such usage is not supported and may very well break your interpreter or cause data corruption (the default encoded versions of Unicode objects are cached inside the objects).
Now, in your particular case, you're probably better off just tweaking site.py directly in your custom Python interpreter rather than relying on sitecustomize.py (see setencoding() in site.py).
To answer your question: yes, this particular API may not be used outside site.py.