2009/4/23 Luke Kenneth Casson Leighton <[email protected]>

> On Thu, Apr 23, 2009 at 5:51 PM, Michael Foord <[email protected]> wrote:
> >
> >
> > 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.
>
>  _cool_.  excellent.
>
> > It certainly *can* be done. It's a lot of work to reimplement the Python
> > C-API though. :-)
>
>  nffh.
>
>  hmm - do the unladen/swallow team know what you've managed to do?
>

Absolutely no idea. :-)

Michael

-- 
http://www.ironpythoninaction.com/
_______________________________________________
[email protected]
http://codespeak.net/mailman/listinfo/pypy-dev

Reply via email to