On Sat, Jun 12, 2010 at 10:32 AM, Terry Reedy <tjre...@udel.edu> wrote: > On 6/12/2010 3:21 AM, Martin v. Loewis wrote: >>> >>> Yeah. I get the policy in general, a proliferation of ctypes stuff could >>> be very bad -- but if code is very careful with type-checking and stuff, >>> it should be possible to get an exception, I'd hope. >> >> Only if you can live with the respective module not being available all >> the time. >> >> The issue is not that you may mistakes in the ctypes code, thus allowing >> users to crash Python. The issue is that if users remove ctypes (which >> they may want to do because it's not trustworthy), then your module will >> stop working (unless you have a fallback for the case that ctypes is >> unavailable). >> >> In general, it's undesirable that absence of some module causes a >> different module to stop working in the standard library, except that >> absence of Tkinter clearly causes IDLE and turtle to stop working. > > Having the absence of ctypes causing IDLE and turtle to stop working would > not be any worse, in a sense, though probably less expected. > >>> Otherwise it makes certain windows-workarounds very problematic. You >>> basically /have/ to write a C extension :| >> >> That's not problematic at all, for the standard library. Just write that >> C extension. > > I suppose one could develop in ctypes and then rewrite when 'stable', though > 'stable' seldom is. > > Would it be possible to write a program that converts a module that uses > ctypes to interface to a dll to a corresponding C extension program that > would compile to a drop in replacement extension module?
I did a similar thing using Java and the JNI, so this seems pretty plausible to me. Having said that, it turned into a time sink very quickly, and there were cases that I never got ironed out- I suspect the same would be true here. Geremy Condra -- http://mail.python.org/mailman/listinfo/python-list
