M.-A. Lemburg wrote: > Martin v. Löwis wrote: >> M.-A. Lemburg wrote: >>> BTW, and intended as offer for compromise, should we instead >>> add the Win32 codes to the errno module (or a new winerrno >>> module) ?! I can write a parser that takes winerror.h and >>> generates the module code. >> Instead won't help: the breakage will still occur. It would >> be possible to put symbolic constants into the except clauses, >> instead of using the numeric values, but you still have to >> add all these "except WindowsError,e" clauses, even if >> the constants were available. > > Right, I meant "instead of using ErrorCode approach". > >> However, in addition would be useful: people will want to >> check for specific Win32 error codes, just because they are >> more descriptive. I propose to call the module "winerror" >> (in parallel to winerror.h, just as the errno module >> parallels errno.h) > > Ok. > >> Adding them all to the errno would work for most cases, >> except that you get conflicts for errno.errcode. > > I think it's better to separate the two - you wouldn't > want to load all the winerror codes on Unix.
I've written a parser which only includes the ERROR_* definitions from the winerror.h file. The generated file is quite large (160kB) and it's currently a Python module defining the symbols and an errorcode dictionary (just like the errno module does). Generating a C extension wouldn't really decrease the size of the mapping tables, since they would also end being dictionaries on the heap. An alternative would be to use a lookup object which then searches in a static C array of data (e.g. a large switch statement which the compiler then optimizes). This would have the advantage of not using up too much process memory and could be shared between Python processes. The downside is that the approach would not be compatible to the errno module interface, since all lookups would have to go through the lookup object, e.g. winerror.ERROR.ACCESS_DENIED instead of: winerror.ERROR_ACCESS_DENIED What do you think ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, May 12 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 ! :::: _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
