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 loewis
Recipients baikie, ezio.melotti, jesterKing, lemburg, loewis, r.david.murray, vstinner
Date 2010-10-29.19:31:46
SpamBayes Score 2.220446e-16
Marked as misclassified No
Message-id <1288380709.74.0.466886933256.issue9377@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2010-10-29 19:31:49loewissetrecipients: + loewis, lemburg, vstinner, baikie, ezio.melotti, r.david.murray, jesterKing
2010-10-29 19:31:49loewissetmessageid: <1288380709.74.0.466886933256.issue9377@psf.upfronthosting.co.za>
2010-10-29 19:31:47loewislinkissue9377 messages
2010-10-29 19:31:46loewiscreate