Showing content from http://mail.python.org/pipermail/python-dev/attachments/20090128/cabc8c16/attachment.htm below:
<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
<br><br>> From: eckhardt@satorlaser.com<br>> To: python-dev@python.org<br>> Subject: Re: [Python-Dev] FormatError() in callproc.c under win32<br>> Date: Tue, 27 Jan 2009 12:16:01 +0100<br>> CC: coder_infidel@hotmail.com<br>> <br>> On Monday 26 January 2009, Martin v. Löwis wrote:<br>> > > In callproc.c from trunk is a function called SetException(), which calls<br>> > > FormatError() only to discard the contents. Can anyone enlighten me to<br>> > > the reasons thereof?<br><br>The left over call to FormatError() looks like a mistake to me.<br><br>> ><br>> > Interestingly enough, the code used to say<br>> ><br>> > PyErr_SetString(PyExc_WindowsError, lpMsgBuf);<br>> ><br>> > Then it was changed to its current form, with a log message of<br>> ><br>> > Changes for windows CE, contributed by Luke Dunstan. Thanks a lot!<br>> ><br>> > See<br>> ><br>> > <br>> http://ctypes.cvs.sourceforge.net/viewvc/ctypes/ctypes/source/callproc.c?hideattic=0&r1=1.127.2.15&r2=1.127.2.16<br>> ><br>> > I suggest you ask Thomas Heller and Luke Dunstan (if available) what the<br>> > rationale for this partial change was.<br>> <br>> I can only guess:<br>> 1. Those changes seem to generate TCHAR strings. This is necessary to compile <br>> it on both win9x (TCHAR=char) and CE (TCHAR=wchar_t). Since win9x was dropped <br>> from the supported platforms, that isn't necessary any more and all the code <br>> could use WCHAR directly.<br><br>As far as I remember TCHAR was char for Windows NT/2K/XP Python builds too, at least at that time, but yes it would be clearer to use WCHAR instead now.<br><br>> 2. Those changes also seem to change a few byte-strings to Unicode-strings, <br>> see format_error(). This is a questionable step, since those are changes that <br>> are visible to Python code. Worse, even on the same platform it could return <br>> different string types when the lookup of the errorcode fails. I wonder if <br>> that is intentional.<br><br>Probably not intentional. Yes, it would be better if the return value was either always char or always WCHAR.<br><br>> <br>> In any case, CCing Luke on the issue, maybe he can clarify things.<br>> <br>> cheers<br>> <br>> Uli<br><br>Good luck,<br>Luke<br><br></body>
</html>
RetroSearch is an open source project built by @garambo
| Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4