[Python-Dev] readd u'' literal support in 3.3?
tseaver at palladion.com
Thu Dec 8 20:03:15 CET 2011
-----BEGIN PGP SIGNED MESSAGE-----
On 12/08/2011 12:26 PM, "Martin v. Löwis" wrote:
>> It would make it possible to share code like this across py2 and
>> a = u'foo'
>> Instead of (with e.g. six):
>> a = u('foo')
>> from __future__ import unicode_literals a = 'foo'
>> I recognize that the last option is probably the way "its meant to
>> be done", but in reality it's just more practical to not fail when
>> literal notation is more specific than strictly necessary.
> You are giving these two options already: - The former works for all
> Python versions. Although it may appear tedious to convert existing
> code to replace all Unicode literals with function calls, it would
> actually be possible/easy to write an automatic converter that does so
> for a complete code base, based on lib2to3.
I guess this could be done to generate "straddling" code from 2-only
code. Note that the overhead of the function call is likely significant
in some cases: generating a module scope constant is the only sane
replacement there, which might be harder to do in a fixer (I haven't
tried to write one yet).
> - the second version is truly practical for all
> applications/libraries that only support 2.6+.
Right. The question is would running more P2 code unmodified in P3 be a
"Good Thing" from the perspective of P3 uptake: developers who run up
against such issues tend to hit "camelback-meet-straw" points and bounce
off the effort. Such a tiny change (a six line patch and an extra '..
note::' in the language reference section on string literal syntax) might
be worth avoiding that risk.
> In addition, there also is another option: - use 2to3, in some form
2to3 is not practical in a "straddling" case:
- - The script is too slow to use in development mode (like being back
in "compile the world" Java / C++ land).
- - The transformed code generates tracebacks that don't match the source.
> So you have already three solutions which are all transitional in
> some sense, and you want yet another option? I fail to see why this
> option is more practical than the options that are already there.
The "redundant" u'*' spelling would be present in Python3 for the same
reason that the equally-reduntant b'*' spelling is present in Python
2.6+: it makes writing portable code simpler.
Tres Seaver +1 540-429-0999 tseaver at palladion.com
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----
More information about the Python-Dev