glyph@divmod.com wrote:
A __future__ import would allow these behaviors to be upgraded module-by-module.
No it wouldn't. __future__ works solely on the semantics of different pieces of syntax, because any syntax changes are purely local to the current module. This doesn't work for datatypes, because data types can cross module boundaries - other modules may still be using the old behaviour, and there's nothing the current module can do about it. Changing all the literals in a module to be unicode instances instead of str instances is merely scratching the surface of the problem - such a module would still cause severe problems for any non-Unicode aware applications that expected it to return strings.
Right now, all -U provides is an option that can't be used on any realistically sized program, so I don't see what the utility is.
There's never been a concerted effort to make even the standard library work under -U. Maybe that should be a goal for Python 2.6 - figure out what tools or changes are needed to make code -U safe, add them, and then update the standard library to use them. PEP 349 (currently deferred, although I don't recall why) discusses some of the issues involved in making code unicode-safe, while still supporting non-unicode safe applications as clients. Cheers, Nick. [1] http://www.python.org/dev/peps/pep-0349/ -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org