ctypes impressions (was: [pypy-dev] bootstrapping issues)
theller at python.net
Thu Jan 16 08:56:05 CET 2003
Christian Tismer <tismer at tismer.com> writes:
> Robin Becker:
> >>>Thomas Heller's ctypes module would seem to be a very good start at the
> >>>generic C interface thing. It is pretty easy to use and although I don't
> >>>have a complete grasp on it was a bit easier to use than calldll. I used
> >>>both to do anygui interfaces to native windows api.
> Thomas Heller:
> > The docs and readme's still need updating, but for the *impatient*
> > I've uploaded a snapshot:
> Well, I had a look at the current version of ctypes,
> in the backgound of this project, of course.
> I only looked into _ctypes.c right now.
> callbacks.c and callproc.c have to be examined as well.
> My impressions are a bit mixed.
> First of all, this looks like a very complete module
> to manipulate every and all flavors of C types.
> I haven't played with it yet, what I promise to do.
> As an extension to the current, C based Python
> implementation, it is without doubt great stuff.
> There are lots of new object types together with
> lots of methods to create and manipulate them.
> What I liked really much (and I would probably like
> to steal this trick) is the most elegant implementation
> of alignment. Interested readers should read and understand
> lines 3309 ff of _ctypes.c .
Ahem, this code is nearly copied from Python's structmodule.c.
So, this idea was someone else's.
> Now to the flipside.
> While this module is for sure of great use for CPython,
> I'm quite reluctant to use it as-is for Minimal Python.
> Reason? It is *way* too big, with 101 KB source and 4330
> While this is very ok with CPython, I think such a big
> module in C is exactly what we don't want for this project,
> since getting rid of large C sources is one of the first
> objectives of the project.
> This is absolutely not meant negatively to Thomas. Your
> module was not designed for this project. In the context
> of CPython, this is the way to do an efficient module.
> Everything has to be written down, in the flat way that C
> requires. That creates many source lines, many type
> denotations, and lots of similar looking methods.
Yes, only counting the lines it is even larger than Jim Fulton's
ExtensionClass.c - but the code is much less dense and easier to read,
But don't take this wrong: I'm not going to argue with you
that something else is needed for Minimal Python.
> For Minimal Python, we need only a small percentage of this.
> We should pick some essential ideas and re-write that part
> in Python. We also only need some basic types to boot up
> the Python engine. Access to real memory can be provided
> by some functions in C, which should be mapped to opcodes
> of the virtual micro-machine.
Thanks for this great review, chris.
More information about the Pypy-dev