[Python-checkins] r45925 - in python/trunk: Lib/tempfile.py Lib/test/test_os.py Misc/NEWS Modules/posixmodule.c

[M.-A. Lemburg]

Martin v. Löwis wrote:
> M.-A. Lemburg wrote:
>> Right. The idea used in errno is to let the Windows
>> error code override the value possibly defined in the
>> C lib (that's why the order of the inscode() in errno
>> matters). This is based on:
>>
>> http://msdn.microsoft.com/library/en-us/winsock/winsock/error_codes_errno_h_errno_and_wsagetlasterror_2.asp?frame=true
> 
> You mean, "The idea used in WSA"?

No, the idea used in errno. A long while ago, we added
the WSA error codes and aliased them to the standard
BSD errno value constants as suggested in the above
document.

> If I understand this correctly, the idea is to define
> 
> #define errno WSAGetLastError()
> 
> (the article actually defines that as "WSAGetLastError",
>  but that is wrong, as WSAGetLastError is a function, and
>  errno is not)
> 
> I can't see how it would help to define such a macro.
> We are talking about Python code here, not C code.

No, this is not what I meant. We should continue to
use WSAGetLastError() explicitly and only for socket
related code.

> Can you please provide a specific patch implementing
> your proposal? I don't get the idea.

It's just a misunderstanding. The code is already there
in the errno module.

>> Perhaps we should have hybrid error code objects that compare
>> equal to more than one integer code, but otherwise behave like
>> integers ?!
> 
> That would be very hacky.

Not really: you often have the situation where you would
like to match a set of values rather than just one value.

Of course, the clean approach would be to use tuples and
__contains__.

Maybe we should have a separate errorcode module that
implements error categories rather than just plain
errno values.

> One thing I could imagine implementing
> is to put two values into WindowsError:
> - errno, with possible values from errno.h (which Microsoft
>   calls "DOS error codes")
> - winerror, with possible values from winerror.h.
> 
> That way, on creating a directory that already exists, you
> would get a WindowsError with errno==EEXIST (17) and
> winerror==ERROR_ALREADY_EXISTS (183).
> 
> That would make my recent library changes unnecessary, and also
> not require changes to applications that currently check
> OSError.errno. 

Sounds like a plan.

>It would have two problems:
> - somebody would have to provide the mapping table from
>   Win32 error codes to "DOS error codes". Microsoft has
>   that in the function _dosmaperr, however, that function
>   is not exported from the CRT.

I don't understand this part.

Couldn't we write a small tool that extracts the mapping
from the Windows APIs ?

Or just use this mapping from ReactOS which was probably
created by doing just that:

http://www.reactos.org/generated/doxygen/de/d02/doserrmap_8h-source.html

> - code that currently catches WindowsError and looks into
>   the errno value would break, as that would not contain
>   Win32 error codes anymore.

I don't think that there is any such code, since the APIs
you changed used to raise OSErrors.

What I'm after is that code relying on the usage of OSError
will continue to work and at the same time improve the
portability of code using e.g. os.mkdir().

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, May 08 2006)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::