[Python-Dev] PEP 414 - Unicode Literals for Python 3 (original) (raw)
Armin Ronacher armin.ronacher at active-4.com
Sun Feb 26 21:47:39 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 ]
Hi,
On 2/26/12 5:45 PM, Antoine Pitrou wrote:
The automatic upgrading of binary strings to unicode strings that would be enabled by this proposal would make it much easier to port such libraries over. What "automatic upgrading" is that talking about? The word "upgrade" is probably something that should be changed. It refers to the fact that 'foo' is a bytestring in 2.x and the same syntax means a unicode string in Python 3. This is exactly what is necessary for interfaces that were promoted to unicode interfaces in Python 3 (for instance Python identifiers, URLs etc.)
Are you talking about urllib.parse perhaps? Not only the parsing module. Headers on the urllib.request module are unicode as well. What the PEP is referring to is the urllib/urlparse and cgi module which was largely consolidated to the urllib package in Python 3.
What does "leveraging a native string" mean here? It means by using a native string to achieve the automatic upgrading which "does the right thing" in a lot of situations.
I'm confused. This PEP talks about unicode literals, not native string literals, so why would these APIs "directly benefit from this support"? The native string literal already exists. It disappears if
unicode_literals
are future imported which is why this is relevant since the unicode literals future import in 2.x is recommended by some for making libraries run in both 2.x and 3.x.
Regards, Armin
- 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 ]