2009/4/7 Armin Rigo <[email protected]> > Hi Luke, > > On Sun, Apr 05, 2009 at 06:10:28PM +0000, Luke Kenneth Casson Leighton > wrote: > > the "fly in the ointment" is that for "full" optimisation to occur, it > > is necessary to "break out" from the prison that intobject.c, > > longobject.c etc. make. > > > > once this prison is opened, by turning the hard-coded python types > > into a more flexible and dynamically-overridable architecture, you > > (the pypy developers) will be free to write modules that will allow > > interoperability between [admittedly recompiled] c-based python > > modules, with no effort [other than recompilation] required on the > > part of the users. > > I am not sure what the point you are trying to make is, just by reading > a bit of the URL you pointed to. Maybe I should read more... :-/ > > I should just point out that supporting C extension modules in PyPy has > been discussed, but the obvious conclusion was that you can't just > recompile the ones from CPython and hope that they work (unless you do > completely evil tricks, e.g. with the garbage collector).
Well, we've achieved binary compatibility with a large proportion of the Python C-API for IronPython (including GC and GIL issues) with Ironclad. http://resolversystems.com/documentation/index.php/Ironclad It certainly *can* be done. It's a lot of work to reimplement the Python C-API though. :-) Michael > > > > A bientot, > > Armin. > _______________________________________________ > [email protected] > http://codespeak.net/mailman/listinfo/pypy-dev > -- http://www.ironpythoninaction.com/
_______________________________________________ [email protected] http://codespeak.net/mailman/listinfo/pypy-dev
