Pyrex praise (repeat)

[François Pinard]

[After sending the following message to `python-dev' yesterday, I now guess
I should probably have included `python-list' as well.  So the below copy.]


Here is how I see Pyrex, and why I have much interest in it.

I do not see Pyrex as a tool whose main goal is converting existing Python
code to C, yet to some extent, it could be used with this goal in head.
It is a tool for the programmer to express various interfaces between C and
Python, using a variant of the Python language augmented with C declarations,
_instead_ of the more usual C language augmented with macros and an API.
The fact that Pyrex produces C code along the road is only part of the
internal mechanics, but is not much of practical interest to the programmer.

Pyrex can be used to extend Python with C code, written in C for the
circumstance, or to wrap pre-existing C libraries.  Pyrex can also be used
to embed Python functions, written and interpreted by Python, within what
would otherwise be a pure C application.  I would guess that Pyrex could
also be used with Python only or (with proper care) with C only, and not
to build an Python-C interface, but these cases are probably not goint to
be usual for me.

The same as it is generally easier and more comfortable to develop and
debug an algorithm or program in Python than in C, would it be only because
C forces you into many details of memory management intricacies, it is
much more easier and more comfortable developing and debugging a Python-C
interface using Pyrex than using more traditional ways: you concentrate
on the interface without having to cautiously swim among reference counts
and the various and numerous API functions or macros.

A neat advantage at using Python instead of C to write your interface is that
you are much less likely to have bugs.  Pyrex knows how to break apart Python
structures and how to rebuild them, it takes care of properly maintaining
reference count invariants, etc. so as long as Pyrex is not itself buggy,
your interface is really on the safe side, bug-wise.  As Python-C interface
bugs might be painful to track down, this is big incentive towards Pyrex.
Being allowed to forget (or avoid learning) all the details of the C API
is yet another good selling point for Pyrex: it would be a spoiling of
resources having many members of a development team to learn the C API for
Python, while I can expect everybody in a programmer team to know Pyrex,
because the learning curve is so small.  Pyrex is more democratic! :-)

A final point, which looks important to me, is that any good wrapping of a
pre-existing C library is best done while giving a Python flavour to the
interface, would it be only for a nicer and natural object orientation.
If the wrapping is done using C to express the interface, the effort of
programming the interface in C while adding more Python-typical paradigms
is complicated by the language distance between C and Python.  But as Pyrex
is very close to Python, Pyrex allows natural and speedy building of more
proper interfaces.  The Pyrex code itself, which holds the glue between
C and Python, is exactly the right place for implementing that necessary
layer meant to reshape the C facilities into Python ways.

-- 
François Pinard   http://www.iro.umontreal.ca/~pinard