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 _______________________________________________ pygtk mailing list [email protected] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
