> having b"" and bytes as aliases for "" and > str in 2.6 would mean that we could write 2.6 code that correctly > expresses the use of binary data -- and we could use u"" and unicode > for code using text, and 2to3 would translate those to "" and str and > the code would be correct 3.0 text processing code.
I see. There's a healthy benefit for 2to3 translation that cannot be accomplished in any other way. This may potentially more than offset the negative impact to the 2.x world where it complexifies the language without any immediate payoff. FWIW, I'm sold on the rationale. Hopefully, this can be confined to just annotation and aliasing but not porting back any C API changes or code that depends on the bytes/text distinction. I worry that as soon as the annotation is made available, it will ripple throughout the code and pervade the language so that it cannot be ignored by Py2.6 coders. It's a bit of a Pandora's Box. > Just being able to (voluntarily! on a > per-module basis!) use a different type name and literal style for > data could help forward-looking programmers get started on making the > distinction clear, thus getting ready for 3.0 without making the jump > just yet (or maintaining a 2.6 and a 3.0 version of the same package > easily, using 2to3 to automatically generate the 3.0 version from the > 2.6 code base). Are we going to be "forward-looking" and change all of the standard library modules? Is this going to pop-up everywhere and become something you have to know about whether or not you're a volunteering forward-looking programmer? I hope not. Raymond _______________________________________________ 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
