Wrapping Python - A function wrapping template

[Daniel Keep]

Kirk McDonald wrote:
> Kirk McDonald wrote:
>> In wrapping Python with D, I have just made a large step:
>>
> 
> I've just done two things with regard to this wrapper:
> 
> First, I've implemented some basic exception wrapping. If a wrapped
> Python API function raises a Python exception, this is now captured and
> thrown as a D exception. If this exception is not caught by user code,
> it is caught by the function wrapping template, and translated back into
> the original Python exception. If a D exception is thrown and not caught
> by user code, the function wrapping template will translate it into a
> Python RuntimeError and pass along the message.

It's like you cracked open my head while I was asleep, scooped it out
and then made some kind of brain-USB connector.  Actually, that might
explain the headache and neck pain...

> On the "to do" list is creating a hierarchy of D exception classes that
> mirrors the hierarchy of Python exceptions, as at the moment there is a
> single "PythonException" class. It might also be nice to provide some
> Python exceptions that mirror various D exceptions, for when those
> escape into the interpreter. (Alternately, one might map them onto an
> appropriate existing Python exception.)

Actually, I never considered doing this, because I set my sights a
little higher: wrapping every single last host class.

I reckon that if we could get RTTI, it could be done.  Then you could
just to something equivalent to:

>>> import host.object.Exception as DException

The trick would be to make them subclassable, which I think would
require more intimate knowledge of the binary format of classes, and
probably generating machine code shims.  But you've got to admit, being
able to do that would be "wow" :)

Failing "real" RTTI, I'd want to write a program that takes a D module
and spits out an RTTI module for it.  I know there's one that already
does this, but I'm not sure when it was last updated.

Plus, I'm itching for a reason to play with Enki :P [1]

<sigh>  When you look at what I have planned for my game engine, the
list of dependencies I have to write is huge.  Oh well... more fun for me :)

> Second, the function wrapper now supports void return types. Imagine my
> suprise when I realised it didn't support them before! (It was sort of a
> "duh" moment.) Adding this support roughly doubled the length of the
> template, which wasn't short to begin with. Each number of arguments the
> wrapped function can accept (from 0 to 10) has its own "static if"
> clause, and now each of these has been doubled, as functions with return
> types to capture must be called differently than those without. Anyway,
> functions with a void return type now return Py_None as per the usual
> Python idiom.

Haha.  Yeah, I got a bit annoyed when I realised that supporting void
generally means duplicating everything.  It would be so much easier if
"void" could be used like a regular type, except that it takes up zero
bytes and never pushes anything on to the stack.

> -Kirk McDonald

	-- Daniel

[1] Every time I read that name, I get the feeling like it should be in
text similar to Yahoo!'s font, with an exclamation mark on the end.  Enki!

-- 
Unlike Knuth, I have neither proven or tried the above; it may not even
make sense.

v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D
i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP  http://hackerkey.com/