On Sat, 15 Jul 2006 14:35:08 +1000, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] wrote:
>>A __future__ import would allow these behaviors to be upgraded module-by-
>>module.
>
>No it wouldn't.
Yes it would! :)
>__future__ works solely on the semantics of different pieces of syntax,
>because any syntax changes are purely local to the current module.
...
>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.
A module with the given __future__ import could be written to expect that
literals are unicode instances instead of str, and encode them appropriately
when passing to modules that expect str. This doesn't solve the problem, but
unlike -U, you can make fixes which will work persistently without having to
treat the type of every string literal as unknown.
The obvious way to write code that works under -U and still works in normal
Python is to .encode('charmap') every value intended to be an octet, and put
'u' in front of every string intended to be unicode. That would seem to
defeat the purpose of changing the default literal type.
_______________________________________________
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
