David Watson <bai...@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 <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
