Chris McDonough <chrism <at> plope.com> writes:
> FWIW, I think this issue's webness may be overestimated. There happens
> to be lots and lots of existing UI code which contains complex
> interactions between unicode literals and nonliterals in web apps, but
> there's also likely lots of nonweb code that has the same issue. If
> e.g. wxPython had already been ported, I think you'd be hearing the same
> sorts of things from folks that had investments in existing
> Python-2-compatible code when trying to port stuff to Py3 (at least if
> they wanted to run on both Python 2 and Python 3 within the same
> codebase).
As I understand it, WSGI happens to explicitly expect str in certain places,
even places where conceptually text should be acceptable. The perception of
webness seems to be substantiated by Nick's comment about endorsement from you,
Armin, Jacob Kaplan-Moss, and Kenneth Reitz for this change. Not that webness is
a bad thing, of course - it's a very important part of the ecosystem.
It would be good to hear from other constituencies about where else (apart from
WSGI and the other uses mentioned in the "APIs and Concepts Using Native
Strings" section of the PEP) native strings are needed. I have encountered such
needs sometimes, but not uncommonly, they appear to be broken APIs that just
expect str even though text should be OK (e.g. cookie APIs, or the sqlite
adapter's insisting on accepting datetimes in text format, but only as native
strings). It would be a shame to leave these APIs as they are indefinitely, and
perhaps using a marker like n('xxx') for native strings would help to remind us
that these areas need addressing at some point.
Regards,
Vinay Sajip
_______________________________________________
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
