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, vstinner
Date 2010-10-17.17:38:49
SpamBayes Score 4.346523e-14
Marked as misclassified No
Message-id <>
In-reply-to <>
Am 15.10.2010 20:03, schrieb David Watson:
> David Watson <> added the comment:
>> As a further note: I think socket.gethostname() is a special case, since this is just about a local setting (i.e. not related to DNS).
> But the hostname *is* commonly intended to be looked up in the
> DNS or whatever name resolution mechanisms are used locally -
> socket.getfqdn(), for instance, works by looking up the result
> using gethostbyaddr() (actually the C function getaddrinfo(),
> followed by gethostbyaddr()).  So I don't see the rationale for
> treating it differently from the results of gethostbyaddr(),
> getnameinfo(), etc.

The result from gethostname likely comes out of machine-local
configuration. It may have non-ASCII in it, which is then likely
encoded in the local encoding. When looking it up in DNS, IDNA
should be applied.

OTOH, output from gethostbyaddr likely comes out of the DNS itself.
Guessing what encoding it may have is futile - other than guessing
that it really ought to be ASCII.

> I can see the point of returning the characters that were
> intended, but code that looked up the returned name would then
> have to be changed to re-encode it to bytes to avoid the
> round-tripping issue when non-ASCII characters are returned.

Python's socket module is clearly focused on the internet, and
intends to support that well. So if you pass a non-ASCII
string, it will have to encode that using IDNA. If that's
not what you want to get, tough luck.
Date User Action Args
2010-10-17 17:38:56loewissetrecipients: + loewis, lemburg, vstinner, baikie, ezio.melotti, jesterKing
2010-10-17 17:38:50loewislinkissue9377 messages
2010-10-17 17:38:49loewiscreate