Brett Cannon <[EMAIL PROTECTED]> writes: > On 8/10/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote: >> > > Then I don't follow what you mean by "moved under os". >> > >> > In other words, to get the exception, do ``from os import >> > WindowsError``. Unfortunately we don't have a generic win module to >> > put it under. Maybe in the platform module instead? >> >> -1 on either. The WindowsError exception needs to in the main exception >> tree. It occurs in too many different modules and applications. That >> is a good reason for being in the main tree. >> > > Where is it used so much? In the stdlib, grepping for WindowsError > recursively in Lib in 2.4 turns up only one module raising it > (subprocess) and only two modules with a total of three places of > catching it (ntpath once, urllib twice). In Module, there are no > hits. >
I don't know how you've been grepping, but the Python api functions to raise WindowsErrors are named like PyErr_SetFromWindowsErr() or so. Typically, WindowsErrors are raised when Win32 API functions fail. In the core extension modules, I find at least mmapmodule.c, posixmodule.c, _subprocess.c, and _winreg.c raising them. It may be a bit hidden, because the docs for _winreg mention only EnvironmentError, but they are wrong: C:\>py Python 2.5a0 (#60, Jul 4 2005, 19:53:27) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import _winreg >>> _winreg.OpenKey(_winreg.HKEY_CLASSES_ROOT, "blah") Traceback (most recent call last): File "<stdin>", line 1, in ? WindowsError: [Errno 2] Das System kann die angegebene Datei nicht finden >>> >> If the name bugs you, I would support renaming it to PlatformError or >> somesuch. That would make it free for use with Mac errors and Linux >> errors. Also, it wouldn't tie a language feature to the name of an >> MS product. >> > > I can compromise to this if others prefer this alternative. Anybody > else have an opinion? Win32 has the FormatError() api to convert error codes into descriptions - these descriptions are very useful, as are the error codes when you catch errors in client code. I would say as long as the Python core contains win32 specific modules like _winreg WindowsError should stay. For the name, I have no preference but I see no need to change it. Thomas PS: For ctypes, it doesn't matter if WindowsError stays or not. No problem to invent my own WindowsError if it goes away. _______________________________________________ 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
