[issue9377] socket, PEP 383: Mishandling of non-ASCII bytes in host/domain names

[David Watson]

David Watson <baikie at users.sourceforge.net> added the comment:

> The surrogateescape mechanism is a very hackish approach, and
> violates the principle that errors should never pass silently.

I don't see how a name resolution API returning non-ASCII bytes
would indicate an error.  If the host table contains a non-ASCII
byte sequence for a host, then that is the host's name - it works
just as well as an ASCII name, both forwards and backwards.

What is hackish is representing char * data as a Unicode string
when there is no native Unicode API to feed it to - there is no
issue here such as file names being bytes on Unix and Unicode on
Windows, so the clean thing to do would be to return a bytes
object.  I suggested the surrogateescape mechanism in order to
retain backwards compatibility.

> However, it solves a real problem - people do run into the problem
> with file names every day. With this problem, I'd say "if it hurts,
> don't do it, then".

But to be more explicit, that's like saying "if it hurts, get
your sysadmin to reconfigure the company network".

----------
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 <report at bugs.python.org>
<http://bugs.python.org/issue9377>
_______________________________________