bad c extension practice
Robin Becker
robin at jessikat.fsnet.co.uk
Wed Aug 23 07:10:48 EDT 2000
Many of the modules in the current CVS tree are handling errors in a
manner which I find unpythonic. A typical example is pyexpat.c which at
the end of initpyexpat does
/* Check for errors */
if (PyErr_Occurred())
Py_FatalError("can't initialize module pyexpat");
the xml-sig group might regard this as a tragedy, but I might wish to
continue and use another parser. The correct behaviour for this sort of
error ought IMHO to be to raise an ImportError clean up any privately
allocated resources and return.
c sources which raise fatal errors
_cursesmodule.c:
_localemodule.c:
_tkinter.c:
almodule.c:
cdmodule.c:
errnomodule.c:
fcntlmodule.c:
fpectlmodule.c:
linuxaudiodev.c:
main.c:
mathmodule.c:
mpzmodule.c:
parsermodule.c:
pcremodule.c:
posixmodule.c:
puremodule.c:
pyexpat.c:
shamodule.c:
stropmodule.c:
syslogmodule.c:
timemodule.c:
timingmodule.c:
--
Robin Becker
More information about the Python-list
mailing list