[Pythonmac-SIG] Python RAD tools

[Donovan Preston]

On Monday, January 14, 2002, at 12:15 PM, Adam Eijdenberg wrote:

>> I just wrapped the IBCarbonRuntime.h header provided by Apple and it 
>> has been very easy for me to load nibs and attach event handlers to 
>> them using Carbon Events.
>
> That looks a fine module, but it is approaching the problem from the 
> opposite end of where I'm coming from. I don't want a Python program 
> with native tie-ins, I want a native program that happens to use Python 
> as a scripting language. Probably only just a philosophical difference, 
> but hopefully it will become clearer as I progress a bit further.

I understand what you are saying. However, I don't really think it's all 
that different from what you are trying to achieve. The advantages of 
using the Python interpreter as the application's main binary and 
performing all OS-level API access using wrapped Python modules are 
many. You don't have to deal with memory management, and you can write 
your application in a much more dynamic fashion. The speed you gain by 
going with a straight-c application which calls out to Python 
occasionally is negligible.

For example, in an application I am writing, I need to be able to do 
some 2d drawing. I started by writing an OpenGL wrapper module which 
would set up the GL context in the constructor and destroy it in the 
destructor, and had a very small set of well-defined calls for drawing, 
clearing the drawing area, and setting and restoring the drawing state. 
This module works equally well on OS 9 as it does on X, and should work 
with a minor amount of tweaking on Windows as well. The only changes 
will be in the C module, not my Python code.

However, the real power revealed itself to me when I decided to write an 
adapter for CoreGraphics on OS X. Since CoreGraphics doesn't run 
anywhere but X, this module will only be useful on X. In 5 minutes, 
thanks to Just's CG module, I was able to write an adapter which set up 
the CG context and implemented all of the drawing and state commands I 
had defined for my GL module. Big deal, you say? Well, I was able, with 
a few minutes more work, to put a pop-up list in a preference panel and 
allow the user to switch between GL and CG rendering. While the program 
is running. With almost no additional work, since all of the setup/tear 
down is handled in the Python constructors/destructors. Basically, the 
switching code looks like this:

self._draw = CGDrawAdapter(self._window)

The simple act of assignment destroys the old context, and the 
constructor for CGDrawAdapter handles the setup for the new context. 
Just like that.

While I admire the progress you have made with your RAD tool, personally 
I would rather spend more of my time programming in Python than in C. 
You'd be amazed at how well it works, and how easy it makes programming 
an otherwise yucky C API.

Donovan