Message115014
| Author |
baikie |
| Recipients |
baikie, ezio.melotti, lemburg, loewis, vstinner |
| Date |
2010年08月26日.18:04:04 |
| SpamBayes Score |
1.3295921e-06 |
| Marked as misclassified |
No |
| Message-id |
<20100826180410.GB5719@dbwatson.ukfsn.org> |
| In-reply-to |
<4C74AFEA.3060601@v.loewis.de> |
| Content |
> 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". |
|