GUIs - A Modest Proposal

[geremy condra]

On Sat, Jun 12, 2010 at 10:32 AM, Terry Reedy <tjreedy at 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