Re: PROPOSAL: A Generic Python Object Interface for Python C Modules

Mark Lutz (mlutz@KaPRE.COM)
Tue, 28 Feb 1995 13:19:56 +0700

> - "Very high level layer": two or three functions that let you exec or
> eval arbitrary Python code given as a string in a module whose name is
> given, passing C values in and getting C values out using
> mkvalue/getargs style format strings. [...]

Cool! This is one of the best ideas I've seen in a long time ;-).
How about running functions by name too?...

But seriously. I've been working with embedding and extending alot
lately, and here's my take: the less a user of embedding/extensions
has to know about the Python's implementation code, the better.

The existing interfaces are great for "power users" (and should
clearly be kept around). But it's pretty tedious to have to study
source files, everytime I need to use tuples, lists, etc. The idea
of an API for handling objects, independent of Python's internal type
representation, would be a Big Win, IMHO.

One minor 'nit': because the API was derived from the existing type
object, it's still somewhat dependant on Python's internal type
representation, at least functionally. But I don't really see much
wrong with this approach; Python's type system works well. And the
API is definately a big improvement over the current situation.

This could bring some coherence to the run-time function interface.
It might even make Python run-time interfaces reasonable to document.
Two thumbs up, dude (I'd give three, but I might get arrested :-).

My $0.02,
Mark L.