Roger Binns wrote:
>>I am not very interested on C compatibility.
>
>
> That will rule out all the gui frameworks, SSL, cryptography
> and numerous other packages. Have a look at what happened to
> Prothon. What ultimately killed it was the problem of having
> a decent library. You don't have to make the C library
> compatibility totally high performance, but having any form of
> it there will make adoption by others easier.
>
There are two kinds of C modules: those that do have a knowledge
of the C API (like sre, tkinter, etc) and those that are just C/C++
libraries which are simply wrapped as modules. For the latter there
are two solutions besides adding a wrapper which makes pyvm appear
as libpython:
- an advanced ctypes module which will make dlopening libraries
and wrapping their symbols behind python functions, a matter of
python code. I'm considering this approach to provide things
like 'raw_input'.
- hacking SWIG. Shouldn't be too hard and will instantly give
us access to wx, qt, etc.
The thing is that the C API of pyvm is IMHO superior and much more fun.
You can wrap the entire sockets module in a couple of hours and also
enjoy it. I wish I could clone myself to port the entire std library
to pyvm -- so much fun it is:)
thanks,
Stelios
--
http://mail.python.org/mailman/listinfo/python-list
