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
_____________________________________________
Metakit mailing list - Metakit@equi4.com
http://www.equi4.com/mailman/listinfo/metakit
