Martin v. Löwis <mar...@v.loewis.de> added the comment: Am 15.10.2010 20:03, schrieb David Watson: > > David Watson <bai...@users.sourceforge.net> 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. ---------- title: socket, PEP 383: Mishandling of non-ASCII bytes in host/domain names -> socket, PEP 383: Mishandling of non-ASCII bytes in host/domain names _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue9377> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
