Nick Coghlan writes: > So, instead of attempting to paper over the problem by reintroducing > u'', perhaps the discussion we should be having is whether or not PEP > 3333's superficially appealing concept of defining an API in terms of > "native strings" is a loser in practice,
+1 to that discussion. str is a different type in the two implementations, binary sludge with essentially undefined semantics in Python 2 and highly standardized text in Python 3. I don't understand how this can be expected to work well, and especially not in a code base that is trying to be portable across Python 2 and 3. I sympathize with Chris's complaint that he has to think about it "again", but in fact, it seems to me that may not be entirely true. AFAICS, having the WSGI APIs mask the difference between str and bytes (or unicode and str, depending on where you're working) requires that you think about it every time you pass something to a WSGI API. I could be wrong, of course (I don't do WSGI stuff, which is why I'm really surprised to hear this, and so I don't know the rationale for the WSGI API decision), but this description of the API just triggers all my alarms. I am somewhat sympathetic to the request for reintroduction of u'' (in my personal use it would just be cruft, so I'm -0.1 on that ground), but I can't see how the WSGI API is an argument for it. Making that case requires showing that the "native string" API makes pragmatic sense, and then that u'' can help. _______________________________________________ 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
