[issue17305] IDNA2008 encoding missing
Marten Lehmann added the comment: There's nice library called idna on PyPI doing idna2008: https://pypi.python.org/pypi/idna/0.1 I'd however prefer this standard encoding to be part of standard python. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17305 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16480] pyvenv 3.3 fails to create symlinks for virtualenv/local/{bin, lib} to virtualenv/{bin, lib}
Marten Lehmann added the comment: Which bug ID? Couldn't find it anywhere in the previous comments. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16480 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16480] pyvenv 3.3 fails to create symlinks for virtualenv/local/{bin, lib} to virtualenv/{bin, lib}
Marten Lehmann added the comment: Could you please tell me, in which exact release or commit this is resolved? I'm using Python 3.3.0 on Ubuntu Precise and I noticed like the others, that e.g. easy_install and pip are installed to venv/local/bin instead of venv/bin and the site-packages folder being used is venv/local/lib/python3.3/dist-packages instead of venv/lib/python3.3/site-packages. Are both issues solved in experimental? So far I only saw a symlink-patch for virtualenv but that doesn't actually fix the problem of being double-local (venv and local-folder within venv), neither dist-packages: https://github.com/pypa/virtualenv/commit/285679cfd326c918676e765e06ed142db66efde0 -- nosy: +marten ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16480 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17305] IDNA2008 encoding missing
Marten Lehmann added the comment:
At least from the GNU people, two separate projects exists for this matter:
libidn, the original IDNA translation (http://www.gnu.org/software/libidn/)
libidn2, the IDNA2008 translation
(http://www.gnu.org/software/libidn/libidn2/manual/libidn2.html)
Btw.: Does Python provide a way to decode the ASCII-representation back to
UTF-8?
name.encode('idna')
'xn--mller-kva.com'
name.encode('idna').decode('utf-8')
u'xn--mller-kva.com'
Otherwise I'd look for Python bindings of libidn2 or idnkit-2.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17305
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17305] IDNA2008 encoding missing
Marten Lehmann added the comment: For the embedded Python examples, please prepend the following lines: from __future__ import unicode_literals name='müller.com' So regarding interoperability: Usually you only use one implementation in your code and hopefully the latest release, but in case someone needs to old one, maybe there should be a separate encodings.idna2008 class. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17305 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17305] IDNA2008 encoding missing
Marten Lehmann added the comment:
IDNA2008 should be backwards compatible. I can try to explain it in a practical
example:
DENIC was the first registry that actually used IDNA2008 - at a time, where not
even libidn2 officially included the changes required for it. This was mainly
due to the point, that the German Latin Small Letter Sharp S ('ß') was treated
differently to other German Umlauts ('ä', 'ö', 'ü') in the original IDNA spec:
It was not punycoded, because the nameprep already replaced it by 'ss'.
Replacing 'ß' with 'ss' is in general correct in German (e.g. if your keyboard
doesn't allow to enter 'ß'), but then 'ä' would have to be replaced by 'ae',
'ö' by 'oe' and 'ü' by 'ue' as well.
Punycoding 'ä', 'ö', 'ü', but not 'ß' was inconsistent and it wouldn't allow to
register a domain name like straße.de, because it was translated to strasse.de.
Therefor DENIC supported IDNA2008 very early to allow the registration of
domain names containing 'ß'.
The only thing I'm aware of in this situation is, that previously straße.de was
translated to strasse.de, while with IDNA2008 it's being translated to
xn--strae-oqa.de. So people that have hardcoded a URL containing 'ß' and who
are expecting it to be translated to 'ss' would fail, because with IDNA2008 it
would be translated to a different ASCII-hostname. But those people could just
change 'ß' to 'ss' in their code and everything would work again.
On the contrary, people that have registered a domain name containing 'ß' in
the meantime couldn't access it right now by specifying the IDN version,
because it would be translated to the wrong domain name with the current Python
IDNA encoding. So the current IDNA-Encoding should be upgraded to IDNA2008.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17305
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17305] IDNA2008 encoding missing
Marten Lehmann added the comment:
I found an interesting link about this issue:
http://www.unicode.org/faq/idn.html
I also checked a domain name of a client that ends with 'straße.de': IE,
Firefox and Chrome still use IDNA2003, Opera already does IDNA2008.
In IDNA2008 a lot of characters aren't allowed any longer (like symbols or
strike-through letters). But I think this doesn't have any practical relevance,
because even while IDNA2003 formally allowed these characters, domain name
registries disallowed to register internationalized domain names containing any
of these characters.
Most registries restricted the allowed characters very strong, e.g. in the .de
zone you cannot use Japanese characters, only those in use within the German
language. Some other registries expect you to submit a language property during
the domain registration and then only special characters within that language
are allowed in the domain name. Also, most registries don't allow to register a
domain name that mixes different languages.
So IDNA2008 is the future and hopefully shouldn't break a lot. I don't know of
any real life use of the IDNA encoding other than DNS / URLs. I don't know how
many existing modules in PyPI working with URLs already make use of the current
encodings.idna class but I guess it would cause more work if they all would
have to change their code to use name.encode('idna2008') or work with an
outdated encoding in the end if unchanged than just silentely switching to
IDNA2008 for encodings.idna and add encodings.idna2003 for those who really
need the old one for some reason. Reminds me a bit on the range() / xrange()
thing. Now the special new xrange() is the default and called just range()
again. I guess in some years we'll look back on the IDNA2003/2008 transition
the same way.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17305
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17305] IDNA2008 encoding missing
New submission from Marten Lehmann:
Since Python 2.3 the idna encoding is available for Internationalized Domain
Names. But the current encoding doesn't work according to the latest version of
the spec.
There is a new IDNA2008 specification (RFCs 5890-5894). Although I'm not very
deep into all the changes, I know that at least the nameprep has changed. For
example, the German sharp S ('ß') isn't replaced by 'ss' any longer.
The attached file shows the difference between the expected translation and the
actual translation.
--
components: Library (Lib)
files: idna_translate.py
messages: 183104
nosy: marten
priority: normal
severity: normal
status: open
title: IDNA2008 encoding missing
type: enhancement
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python
3.4, Python 3.5
Added file: http://bugs.python.org/file29256/idna_translate.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17305
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
