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 baikie
Recipients baikie, ezio.melotti, jesterKing, lemburg, loewis, vstinner
Date 2010-10-15.18:03:42
SpamBayes Score 2.912115e-13
Marked as misclassified No
Message-id <20101015180336.GA3180@dbwatson.ukfsn.org>
In-reply-to <1287076504.72.0.973773564959.issue9377@psf.upfronthosting.co.za>
Content
> 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.

POSIX says of the name lookup functions that "in many cases" they
are implemented by the Domain Name System, not that they always
are, so a name intended for lookup need not be ASCII-only either.

> We should then assume that it is encoded in the locale encoding (in particular, that it is encoded in mbcs on Windows).

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.
History
Date User Action Args
2010-10-15 18:03:44baikiesetrecipients: + baikie, lemburg, loewis, vstinner, ezio.melotti, jesterKing
2010-10-15 18:03:43baikielinkissue9377 messages
2010-10-15 18:03:42baikiecreate