[Python-Dev] PEP 414 - Unicode Literals for Python 3

["Martin v. Löwis"]

>> The PEP author is supposed to collect all arguments, even the ones he
>> doesn't agree with, and refute them.
> I brought up all the arguments that were I knew about before I submitted
> this mailinglist thread and I had since not updated it.

This is fine, of course. I still hope you will update it now, even
though it has been accepted.

>> This is incorrect: even though the native string type indeed is no longer
>> available, it is *not* consequential that it has to be labeled as byte
>> string. Instead, you can use the str() function.
> Obviously it means not available by syntax.

I agree that the native string type is no longer supported by syntax in
that approach.

>> It may be that you don't like that solution for some reason. If so, please
>> mention the approach in the PEP, along with your reason for not liking it.
> If by str() you mean using "str('x')" as replacement for 'x' in both 2.x
> and 3.x with __future__ imports as a replacement for native string
> literals, please mention why this is better than u(), s(), n() etc.  It
> would be equally slow than a custom wrapper function and it would not
> support non-ascii characters.

That's not the point. The point is that the PEP ought to mention it as
an alternative, instead of making the false claim that "it has to be
labeled as byte string" (which I take as using a b"" prefix). Feel free
to write something like

"... it either has to be labelled as a byte string, or wrapped into
a function call, e.g. using the str() function. This would be slow and
would not support non-ascii characters"

My whole point here is that I want the PEP to mention it, not this
email thread.

In addition, if you are using this very phrasing that I propose,
I would then claim that

a) it is not slow (certainly not as slow as a custom wrapper (*)), and
b) it's not a problem that it is ASCII-only, since native strings
   are *practically* restricted to ASCII, anyway (even though
   not theoretically)

In turn, I would ask that this counter-argument of mine is also
reflected in the PEP.

The whole point of the PEP process is that it settles disputes.
Part of that settling is to avoid arguments which go in circles.
To that effect, the PEP author ideally should *quickly* update
the PEP, along with writing responses, so that anybody repeating
an argument could be pointed to the PEP in order to shut up.

HTH,
Martin

(*) This is also something that Guido requested at some point
from the PEP: that it fairly analyses efficient implementations
of potential wrapper functions, taking C implementations into
account as well.