>> - "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 ;-).
Of course, this topic was inspired by some of your posts.
> 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.
Agreed.
> 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.
Yup.
> 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.
Yes.
> 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 :-).
Thanks.
--
-- Jim Fulton jfulton@mailqvarsa.er.usgs.gov (703) 648-5622
U.S. Geological Survey, Reston VA 22092
This message is being posted to obtain or provide technical information
relating to my duties at the U.S. Geological Survey.