[Python-Dev] readd u'' literal support in 3.3?

[Stephen J. Turnbull]

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.