"Martin v. Löwis" <martin at v.loewis.de> writes: > Guido van Rossum wrote: >> On the other hand it breaks one of the most fundamental Python >> guidelines: if you get a core dump (segfault etc.) it's a bug in >> Python or in a 3rd party extension, not in *your* Python code. An >> exception would have to be made for any code that uses ctypes, as it >> is usually trivial to cause core dumps with ctypes (I'd venture it's >> hard to avoid them ;-). >> >> I don't expect this to count against including ctypes; but I do want >> it to be dealt with somehow! > > I think the strongest point *for* ctypes is the inclusion of dl > in the source distribution, which has the very same flaws as > ctypes in terms of crashability. > > So as for dealing with it "somehow": I would make ctypes a dynamically > loaded module (ctypes.pyd), so administrators could remove it, and > I could also make it a separate option in the Windows installer, > so administrators could reject to install it. Sounds good, although it should be noted that ctypes is a package now, with a ctypes.wrap subpackage (contains the code generator), a ctypes.macholib subpackage (contains Bob Ippolitos macholib for OS X), and ctypes.test subpackage whcih contains several test modules. Plus the _ctypes.(dll|so) extension module. Thomas
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