[Python-Dev] PEP 414 - Unicode Literals for Python 3 (original) (raw)
Nick Coghlan ncoghlan at gmail.com
Tue Feb 28 12:42:54 CET 2012
- Previous message: [Python-Dev] PEP 414 - Unicode Literals for Python 3
- Next message: [Python-Dev] PEP 414 - Unicode Literals for Python 3
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Tue, Feb 28, 2012 at 5:56 PM, Matej Cepl <mcepl at redhat.com> wrote:
He cannot, because he would have to throw away whole PEP ... it is all based on non-sensical concept of "native string". There is no such animal (there are only strings and bytes, although they are incorrectly named Unicode strings and strings in Python 2), and whole PEP is just "I don't like Python 3 and I want it to be reverted back to Python 2".
It doesn't matter anymore now, but I just needed to put it off my chest.
If you don't know what a native string is, then you need to study more to understand why Armin's PEP exists and why it is useful. I suggest starting with PEP 3333 (the WSGI update to v1.0.1 that first clearly defined the concept of a native string: http://www.python.org/dev/peps/pep-3333/#a-note-on-string-types).
There are concrete, practical reasons why the lack of Unicode literals in Python 3 makes porting harder than it needs to be. Are they insurmountable? No, of course not - there are plenty of successful ports already that demonstate porting it quite feasible with existing tools. But the existing approaches require that, in order to be forward compatible with Python 3, a program must be made worse in Python 2 (i.e. harder to read and harder to write correctly for someone that hasn't learned Python 3 yet). Restoring unicode literal support in 3.3 is a pragmatic step that allows a lot of code to just work on Python 3. Most 2.6+ code that still doesn't work on Python 3 even after this change will be made better (or at least not made substantially worse) by the additional changes necessary for forward compatibility.
Unicode literals are somewhat unique in their impact on porting efforts, as they show up everywhere in Unicode correct code in Python 2. The diffs that will be needed to correctly tag bytestrings in such code under Python 2 are tiny compared to those that would be needed to strip the u"" prefixes.
Regards, Nick.
-- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
- Previous message: [Python-Dev] PEP 414 - Unicode Literals for Python 3
- Next message: [Python-Dev] PEP 414 - Unicode Literals for Python 3
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]