[Python-Dev] deleting setdefaultencoding iin site.py is evil (original) (raw)

Guido van Rossum guido at python.org
Thu Aug 27 18:50:38 CEST 2009

2009/8/27 Barry Warsaw <barry at python.org>:

On Aug 27, 2009, at 9:08 AM, exarkun at twistedmatrix.com wrote:

This is what I meant when I said what I said about correct code.  If you're happy to have encoding errors and corrupt data, then I guess you're happy to have a function like setdefaultencoding. Whatever happened to "we're all adults here"[1]?  I have no problem with making it difficult but possible to write buggy but practical code.  Software engineering is a messy business.

Being adults about it also means when to give up. Chris, please stop arguing about this. There are plenty of techniques you can use to get what you want without changing Python, for example virtualenv, which allows you to create a custom Python environment for each project. Or you could switch to Python 3.1, whose different approach to distinguishing between encoded and decoded string means that you won't have to worry about the default encoding quite as much (and you are free to change the default filesystem encoding in Py3k). Or you could invoke python -S, which skips site.py and sitecustomize.py, so you are free to mess up any way you want.

The fundamental reason the designers of Python's 2.x standard library don't want you to be able to set the default encoding in your app, is that the standard library is written with the assumption that the default encoding is fixed, and no guarantees about the correct workings of the standard library can be made when you change it. There are no tests for this situation. Nobody knows what will fail when. And you (or worse, your users) will come back to us with complaints if the standard library suddenly starts doing things you didn't expect.

-- --Guido van Rossum (home page: http://www.python.org/~guido/)

More information about the Python-Dev mailing list