A lot of people have been asking me why I don't use some sort of
autogenerating tool to create the libparted Python bindings.  There are
numerous tools out there, so shouldn't one of them solve my problem?  Sort
of, but not really.

I took a look at the following tools:

    Pyrex
    SWIG
    whatever PyGTK uses

The autogenerating tools are great for certain kinds of projects, but in the
case of the Python bindings for libparted, there are some specific cases where
the automatic binding generators do not work as I wanted them to.  Namely:

    1) libparted makes extensive use of its own types.  I wanted these
       implemented as Python classes.  None of the above mentioned tools
       would do this to my liking.  The Python classes are implemented so
       they store the members of the libparted types as object members,
       when appropriate and useful, in Python.

    2) A lot of functions in libparted do not make sense to have in
       Python, so I do not want those translated to Python functions.

    3) libparted is implemented as a standard C library and doesn't try
       to mimic objects like other C libraries (GTK+, for instance).  So
       what I really wanted to do is create a simple 1:1 function mapping,
       but extended so that the libparted types would be translated to
       Python objects.  On top of that, I would write native Python that
       uses the 1:1 mapping layer to add additional functionality.  With
       that idea, pyparted is a hybrid C+Python module and directly
       converting the API via an automatic tool still left a lot of work
       to do anyway.

    4) There is no good way to map an enumeration in C to module attributes
       in Python (or class attributes).  I did not like the output of the
       autogenerated tools.

    5) Additional error checking needed to happen in the type classes
       created in the Python layer.  Bounds checking, type checking on
       instantiation parameters, and so forth.  The autogenerating tools
       didn't really make this clear.

    6) I wanted the Python module to correctly implement exceptions at
       the Python level and not directly map to the libparted ones.

    7) I want to understand the Python C module code rather than treat it
       as a blackbox and rely on whatever another tool created for me.

All of these reasons and more are why I have written the Python module by
hand instead of relying partly on an automatic tool.  Will this project
always be maintained by hand?  Who knows?  For now it is, but this could
change.

-- 
David Cantrell <dcantrell@redhat.com>
