Re: [pygtk] Overriding GObject methods in Python

[John K Luebs <jkluebs luebsphoto com>]

On Fri, Nov 24, 2006 at 02:01:55PM +0100, Hrvoje Nikšić wrote:
> On Thu, 2006-11-23 at 17:20 +0100, Johan Dahlin wrote:
> > You seem to be very worried about performance. 
> 
> Only for low-level code, where C would be used for efficiency.  Ideally,
> calling C methods from C code should be as fast as invoking a function
> via a function pointer (possibly achieved by caching the method lookup).
> Calling Python from C or C from Python can involve hashtable lookups,
> performance is obviously not a priority there.
> 
> > I advise you to try it out and see if it meets your requirements.
> > 
> > If it doesn't, rewrite the whole thing in C.
> 
> Your advice is sound and it works well for most projects.  For some
> larger projects a bit more planning is needed because by the time the
> project reaches a prototype stage, it might be too late to rewrite it in
> C.

If that is the case then the project manager has no business in software
design and the business deserves a lawsuit by its investors. If it's
only a prototype, then it is assumed that large portions of the system
may need to be rearchitected.

Anyway, what you are asking for cannot be done with the traditional
hammering out of C and C++ code. C does not provide the introspection
 features, nor does C++. Getting the static performance with the
 dynamic features is readily accomplished with a code generator.

Have you looked at how pygtk is built.

I realize that the system in pygtk is not perfect, but it should give you
some good ideas that in the context of a properly planned large project
should be easy to pursue. PyGTK basically consists of some s-expr
like definitions that generate many of the wrappers.

The problems with the pygtk wrappers (ie those things that require
hand written shit) are mainly due to complexities in certain
parts of GTK+ and the want to provide constructs that are
very much comfortable to Python programmers.

By lightening up on the last requirment and/or writing objects
with interfaces that are "easy to wrap", you will do away with
these problems.

It is also possible to write a code generating system that is
smarter than pygtk's, although this will be more complex. The pygtk
system works well considering how simple it is.

 
> The moral of the story is not premature optimization, nor is it my
> intention to imply that Python is as slow as Morass (it's in fact
> significantly faster, although not by an order of magnitude).  The point
> is that performance has to be at least considered when choosing the
> underlying technology and design, because the underlying technology is
>
If the project is poorly planned then you are screwed in all cases, no
matter the underlying technology. I think the technology in this
case is being used as a scapegoat for shitty planning.

There have been some amazing large systems done with major components,
the keyword being components, in highly dynamic languages. It has been
my experience that there is almost never a large system where some part
of the glue cannot be a "slow" language. It is just the nature of a
large system.

 -jkl