[Metakit] [Fwd: memory leaks in python interface [was Hash view questions]]

[Jean-Claude Wippler]

Ralf Schmitt wrote:

> Brian Kelley schrieb:
>> Well, I should get off my butt here.   I agree that the metakit
>> interface needs to be rewritten and I have started a swig'd version
>> that is going slowly.  The first pass is a "low-level" interface that
>> acts like C++.  If anyone wants to help me flesh it out, I'll start a
>> sourceforge repository so we can make the second pass to be more
>> pythonic.
>>
> After working a bit with the existing codebase, I thought the best  
> thing to do, was to clean it up a bit, remove some C++ magic and be  
> done with it - after all this is working code. JCW  is  a bit quiet  
> on this topic and so my motivation to  heavily patch the python  
> interface is near zero as this makes integrating patches made in  
> the metakit cvs repository a pain in the ass.

Quiet, but definitely interested.  I decided to wait a bit to gauge  
what the response is - besides, I'm afraid to stifle any good  
initiatives.

I don't know what the barrier is for fixing things and altering  
whatever needs to be improved.  Gordon's code was written a long time  
ago, and from what I remember he wrote the SCXX wrapper to simplify  
the Mk4py wrapper (there was an older very crude wrapper by me, ages  
before that).  SWIG wasn't good enough to wrap MK's C++ code back  
then, but no doubt it'll be much better at it now.

Have got no personal preference w.r.t. tweaking Mk4py vs. creating a  
new Python wrapper over a SWIG binding.  I can see some pro's and  
con's either way.

In terms of integrating changes, I can't open up the equi4.com site  
to CVS check-in, but the least I can do is accept patches and changes  
on the existing CVS repository (there's now also a CVStrac web-based  
issue tracker which may help ensure that no details fall through the  
cracks).  For a more concerted collaborative effort, I agree that the  
current public project sites offer more flexibility.

> You know Joel's attitude on this topic?
> http://www.joelonsoftware.com/articles/fog0000000069.html

Spot on.  I feel that pain EVERY DAY, in my work on the Vlerq project  
(which is very much alive, but essentially a one-man effort).

Looking forward, I would think that a Python-code-on-top-of-a-thin-C/C 
++-binding has the most chances of creating a really good fit for the  
language.  I see my task as coming up with an engine and a bunch of  
super-thin C bindings, letting different language experts create a  
good fit for each case.  In my experience, both tasks are hard and  
totally complementary.  I'm limiting myself to the first part in  
Vlerq, and have added core C bindings for, in chronological order:  
Tcl, Python, Ruby, and Lua.  I'll also add that the Vlerq code is  
work-in-progress and not ready for prime time.  Some thoughts on this  
subject are at http://www.vlerq.org/vqr/318

So on the one hand, the core Metakit C++ code is unlikely to ever go  
through any further major revisions, making tweaks to what there is a  
sensible option.  On the other hand, creating a new very Pythonic  
wrapper may lead to something which can one day be migrated to use a  
new engine from the Vlerq project.  Beware of coding things too  
generally in an attempt to cover all bases today, though.  It seems  
to me that the main challenge for a Python wrapper is to present a  
model that works fantastically well in Python - actual code can  
easily be changed later, even if it was written completely towards  
either the current Mk4py or Brian's SWIG binding.

Maybe the answer is not either/or?

-jcw