This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author lemburg
Recipients baikie, ezio.melotti, jesterKing, lemburg, loewis, r.david.murray, vstinner
Date 2010-10-29.20:09:03
SpamBayes Score 0.0
Marked as misclassified No
Message-id <4CCB29DD.6090502@egenix.com>
In-reply-to <1288380709.74.0.466886933256.issue9377@psf.upfronthosting.co.za>
Content
Martin v. Löwis wrote:
> 
> Martin v. Löwis <martin@v.loewis.de> added the comment:
> 
> The Solaris case then is already supported, with no change required: if Solaris bans non-ASCII in the network configuration (or, rather, recommends to use IDNA), then this will work fine with the current code.
> 
> The Josefsson AI_IDN flag is irrelevant to Python, IMO: it treats byte names as locale-encoded, and converts them with IDNA. Python 3 users really should use Unicode strings in the first place for non-ASCII data, in which case the socket.getaddrinfo uses IDNA, anyway. However, it can't hurt to expose this flag if the underlying C library supports it. AI_CANONIDN might be interesting to implement, but I'd rather wait whether this finds RFC approval. In any case, undoing IDNA is orthogonal to this issue (which is about non-ASCII data returned from the socket API).
> 
> If anything needs to be done on Unix, I think that the gethostname result should be decoded using the file system encoding; I then don't mind using surrogate escape there for good measure. This won't hurt systems that restrict host names to ASCII, and may do some good for systems that don't.

Wouldn't it be better to also attempt to decode the name using IDNA
in case the name starts with the IDNA prefix ?

This would then also cover the Solaris case.
History
Date User Action Args
2010-10-29 20:09:05lemburgsetrecipients: + lemburg, loewis, vstinner, baikie, ezio.melotti, r.david.murray, jesterKing
2010-10-29 20:09:04lemburglinkissue9377 messages
2010-10-29 20:09:03lemburgcreate