Python bindings

Hi all,

I spent some time studying Pyrex_, and wonder if anybody considered it
for a next-generation Python bindings implementation.

The toolset lets you wrap in a extremely pythonic way an external
library, without the swig hassle.

For example, consider the following scripts, that is all what's needed
to wrap the apr pool within a Python object (class!!).

The first is the "declaration", the interface of the module. Note the
"Cdef"s, that expose **just** the needed functionalities::

    cdef extern from "apr_general.h":
        int apr_initialize()
        void apr_terminate()

    cdef extern from "apr_pools.h":
        ctypedef struct apr_pool_t

        int apr_pool_create(apr_pool_t **pool, apr_pool_t *parent)

    cdef class Pool:
        cdef apr_pool_t *pool
    
The second, even simpler one, is the implementation. Note: here we
are implementing what will become a CPython class, using an almost
Python syntax, with light C tweaks::

    cdef class Pool:
        def __new__(self, Pool parent = None):
            if parent:
                apr_pool_create(&self.pool, parent.pool)
            else:
                apr_pool_create(&self.pool, NULL)

    def initialize():
        apr_initialize()

    def terminate():
        apr_terminate()

The third, the usual Python setup::

    from distutils.core import setup
    from distutils.extension import Extension
    from Pyrex.Distutils import build_ext

    setup(
      name = 'svn',
      ext_modules=[
        Extension("apr", ["apr.pyx"],
                  include_dirs=["/usr/include/apr-0"],
                  libraries=["apr-0"]),
        ],
      cmdclass = {'build_ext': build_ext}
    )

Finally, the Makefile recipe::

    all:
            python Setup.py build_ext --inplace

    clean:
            rm -f *.c *.o *.so *~ core
            rm -rf build

This allows me to::

    $ make
    python Setup.py build_ext --inplace
    running build_ext
    building 'apr' extension
    creating build
    creating build/temp.linux-i686-2.3
    gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wall \
        -Wstrict-prototypes -fPIC -I/usr/include/apr-0 \
        -I/usr/include/python2.3 -c apr.c -o build/temp.linux-i686-2.3/apr.o
    apr.c: In function `__pyx_f_3apr_initialize':
    apr.c:99: warning: label `__pyx_L1' defined but not used
    ....
    gcc -pthread -shared build/temp.linux-i686-2.3/apr.o -lapr-0 -o apr.so

Then with a "but-is-it-for-real-face-with-a-?-nose::

    $ ls -lrt
    totale 73
    -rw-r--r-- 1 lele lele 92 1 apr 03:44 Makefile
    -rw-r--r-- 1 lele lele 322 1 apr 03:50 Setup.py
    -rw-rw-r-- 1 lele lele 513 1 apr 04:21 apr.pyx
    -rw-rw-r-- 1 lele lele 501 1 apr 04:21 apr.pxd
    -rw-rw-r-- 1 lele lele 11865 18 apr 19:18 apr.c
    drwxrwxr-x 3 lele lele 1024 18 apr 19:18 build
    -rwxrwxr-x 1 lele lele 56241 18 apr 19:18 apr.so

And finally, ashtonished::

    $ python
    Python 2.3.3 (#2, Feb 24 2004, 09:29:20)
    [GCC 3.3.3 (Debian)] on linux2
    Type "help", "copyright", "credits" or "license" for more information.
>>> import apr
>>> apr.initialize()
>>> pool = apr.Pool()
>>> print pool
    <apr.Pool object at 0x401d6050>
>>> subpool = apr.Pool(pool)
>>> print subpool
    <apr.Pool object at 0x401d6060>

While it's clear that this would benefit only the Python side of the
bindings, I think that the new layer would be more powerful and at the
same time much more manageable.

What do you think?

ciao, lele.

.. _pyrex: http://www.cosc.canterbury.ac.nz/~greg/python/Pyrex/

-- 
nickname: Lele Gaifax	| Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas	| comincerò ad aver paura di chi mi copia.
email: lele@seldati.it	|		-- Fortunato Depero, 1929.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org