The PEP does not consider an alternative idea such as using "from __future__
import unicode_literals" in code which needs to run on 2.x, together with e.g. a
callable n('xxx') which can be used where native strings are needed. This avoids
the need to reintroduce the u'xxx' literal syntax, makes it explicit where
native strings are needed, is less obtrusive that u('xxx') or u'xxx' because
typically there will be vastly fewer places where you need native strings, and
is unlikely to impose a major runtime penalty when compared with u('xxx')
(again, because of the lower frequency of occurrence).
Even if you have arguments against this idea, I think it's at least worth
mentioning in the PEP with any counter-arguments you have.
Regards,
Vinay Sajip
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4