2009/8/27 Barry Warsaw <ba...@python.org>: > On Aug 27, 2009, at 9:08 AM, exar...@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/) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
