Hello! While the development of pymunk is not as fast as it was in the beginning its still not in any way dead. I actually checked in a bugfix last Sunday
I try to monitor what happens with pymunk at least once a week (google pymunk, last 7 days) and try to be quick to answer any questions, comments or bugreports I find. However, if you really want a quick response to something, then its usually best to either add it as an issue report on the pymunk google code page (as it sends me an email), or email me directly at vb @ viblo.se
That post you found is a bit outdated now. Let me outline how pymunk works today:
I have a script, generate_bindings.py (in the tools folder in svn), that when run on the source of chipmunk creates the _chipmunk.py low level binding file. This file is ready to use, however it is not very convenient as it is just a straight low level binding from the C-code. Therefor pymunk has another layer on top of that, which transforms the C style API into something that feels more pythonic to use. (My goal with pymunk is to make it feel like it was all coded in python, and that it should not be visible that a C library is in the bottom, except for the speed gains)
To actually interface with the C code _chipmunk uses ctypes, the FFI standard library that is part of the python distribution which can interface with dynamic c libraries directly. This has some advantages that I like
- It is part of the standard library
- you don't need to compile anything special for python, as long as you have the C library you want to call in a dll (or .so or .dylib on linux/osx)
- It is quite cross-platform between python versions. (both different versions of the standard runtime 2.6,2.7 3.0 and so on, but also for example pypy)
- You only write python code to interface with the C library, no special markup, no extra c code and so on.
- Because of it being only python code that any python programmer can understand, everyone that is using pymunk should be able to read its code if necessary.
- It is easy to understand, not so much magic happening
- It is easy to compile everything, as the only thing you need to worry about is the c library (Chipmunk in the case of pymunk, which is very easy to compile)
- No extra dependencies, python + a compiled library is all you need
The main disadvantages I can see is that the speed is probably a bit slower than other binding methods. However, I don't see it as a really big problem as I think that most time spent in an physics application will be in the actual physics simulation, or outside in the rest of the application in for example drawing and logic. I have not done any real speed comparisons between ctypes and other binding methods, but I have done tests in the python code that indicates that the limit is almost always in other parts of the application even for worst-case type of applications.
Except for the speed another disadvantage is the autogeneration, it is quite basic in ctypes. On the other hand you don't get a perfect python style library from any binding system without a fair amount of work, and with ctypes it's at least easy to understand what's happening and how to work with it.
Before I created pymunk I tried using SWIG a bit (worked a bit on a plugin to pyogre, the python Ogre binding), and I have also looked at other ways to do FFI, but I like ctypes best so far
.