As part of the registry work, Im toying with the idea of a standard "win32 exception" error in the Python core. The reasons why I think a standard exception would be useful are: * Single body of code that knows how to raise these exceptions. Eg, whenever an extension module needs to report that a Win32 API function failed, they can use the core routines to create the exception object - just like they can with OSError. This ensures consistency, and saves each extension module author from reinventing the wheel. * No confusion about what exception Python programmers should catch. In the same way that "OSError" will be thrown any time the C runtime library fails, the "Win32Error" exception will be thrown whenever a Win32 API function (called directly) fails. This has come up now that I am looking at a "win32reg" (or "_win32reg") module for inclusion in Python 1.6. It makes sense to me that rather than creating specific exceptions for each new module of this ilk, we define a single exception able to be shared by any core or 3rd party module that needs it. Ideally, this exception should derive from "EnvironmentError" - however, this is pretty specific to the OSError mechanics. The other alternatives are to create a Win32Error that derives directly from "StandardError", or to introduce an intermediate "PlatformError". The Win32 extensions have been doing this for ages (ie, every win32*.pyd module shares and raises the same exception object) and IMO it is a good thing. If we do go this route, the Win32 exceptions could also share this exception object, which is, IMO, also a good thing (in the same way that extension modules now can already raise OSError without a need to redefine the semantics each time) Does anyone have thoughts on this? Is it a good thing or a bad thing? Have-I-made-the-comparison-to-OSError-enough?-ly, Mark.
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