Movatterモバイル変換
[0]ホーム
[Python-Dev] PEP 414 - Unicode Literals for Python 3
Chris McDonoughchrism at plope.com
Mon Feb 27 20:50:21 CET 2012
On Mon, 2012-02-27 at 13:44 -0500, Terry Reedy wrote:> On 2/27/2012 1:01 PM, Chris McDonough wrote:> > On Mon, 2012-02-27 at 12:41 -0500, R. David Murray wrote:> >> Eh? The 2.6 version would also be u('that'). That's the whole point> >> of the idiom. You'll need a better counter argument than that.> >> > The best argument is that there already exists tons and tons of Python 2> > code that already does:> >> > u'that'> >> > Needing to change it to:> >> > u('that')> >> > 1) Requires effort on the part of a from-Python-2-porter to service> > the aesthetic and populist goal of not having an explicit> > but redundant-under-Py3 literal syntax that says "this is text".>> This is a point, though this would be a one-time conversion by a 2to23> converter that would be part of other needed conversions, some by hand.> I presume that most 2.6 code has problems other than u'' when attempting> to run under 3.x.>> > 2) Won't atually meet the aesthetic goal, as> > it's uglier and slower under *both* Python 2 and Python 3.>> Less relevant. The minor ugliness would be in dual-version code, but not> Python 3 itself.>> > So the populist argument remains.. "it's too confusing for people who> > learn Python 3 as a new language to have a redundant syntax". But we've> > had such a syntax in Python 2 for years with b'', and, as mentioned by> > Armin's PEP single-quoted vs. triple-quoted strings forever.> >> > I just don't understand the pushback here at all.>> For one thing, u'' does not solve the problem for 3.1 and 3.2, while u()> does. 3.2 will be around for years. For one example, it will be in the> April long-term-support release of Ubuntu. For another, PyPy is working> on a 3.2 compatible version to come out and be put into use this year.I suspect not everyone lives and dies by OS distribution release supportpolicies. Many folks are both willing and capable to install a newerPython on an older OS.It's unfortunate that Python 3 < 3.3 does not have the syntax, andpeople like me who have a long-term need to "straddle" are to blame; wedidn't provide useful feedback early enough to avoid the mistake. Thatsaid, it seems like preventing a reintroduction of u'' literal syntaxwould presume that two wrongs make a right. By our own scheduleestimate of Python 3 takeup, many people won't be even thinking aboutporting any Python 2 code to 3 until years from now.> > This is such a nobrainer.>> I could claim that a solution that also works for 3.1 and 3.2 is a> nobrainer. It depends on how one weighs different factors.An argument for the reintroduction of u'' literal syntax in Python >=3.3 is not necessarily an argument against the utility of some automatedtool conversion support for porting a Python 2 app to a function-basedu() syntax so it can run in Python 3 < 3.2.Tools like "2to23" or whatever can obviously be parameterized to emitslightly different 3.2-compatible and 3.3-compatible code. It's almostcertain that it will need forward-version-aware modes like this anywayas newer idioms are added to 3.X that make code prettier or moreefficient completely independent of u'' support.Currently we handle 3.2 compatibility in packages that "straddle" viasix-like functions. We can continue doing this as necessary. If thestdlib tooling helps, great. In an emit-function-based-syntax mode, theconversion code would almost certainly need to rely on the import of anexternally downloadable module like six, for compatibility under bothPython 2 and 3 because there's no opportunity to go back in time andmake "u()" available for older releases unless it was like inlined inevery module during the conversion.But if somebody only wants to target 3.3+, and it means they don't haveto rely on a six-like module to provide u(), great.- C
More information about the Python-Devmailing list
[8]ページ先頭