[Python-Dev] deleting setdefaultencoding iin site.py is evil

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