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.