[pypy-dev] offtopic, ontopic, ...

Stefan Behnel stefan_ml at behnel.de
Tue Feb 14 18:24:44 CET 2012

Armin Rigo, 14.02.2012 16:12:
> On Tue, Feb 14, 2012 at 14:12, Stefan Behnel wrote:
>> Hmm, if that is so, how would you ever want to make PyPy bidirectionally
>> interface with anything at all? How does ctypes even work in PyPy?
> I believe you are not understanding my point.  Obviously ctypes works
> in PyPy, and not, I believe, in a particularly "lucky" way at all.  It
> works by not being written as C code at all, but as (Python and)
> RPython code.  The difference of levels between C and RPython is
> essential in PyPy.  I just gave tons of examples of why it is so.  I
> know it's not a perfect solution for everybody; but we think that
> writing C code (or generating it straight from something else) is not
> the most flexible way to develop software.

Regardless of what you (or I) think, software is being written that way
while we speak. A lot of software.

I mean, seriously, software is being written in Cobol and Java while we
speak. That "most flexible way" has little to do with reality. There is no
such thing as "one ring to bind them all". Except, perhaps, C.

> You may not agree with
> that, and you're free too; but consider that we would be unlikely to
> have a JIT in PyPy at all without the approach we took, so we think
> there is some merit in it.

It sounds like the JVM approach to me, though. Tons of great software has
been dumped and rewritten during the last 16 years in order to get
something (anything, really) that runs on top of the JVM. Let's not require
PyPy users to take the same road. Even the .NET approach is smarter here.

> Note that I'm pushing so much for a Cython that would emit Python code
> instead of C --- but that's mostly for performance reasons on top of
> PyPy.  The alternative, which is quicker and only slightly more
> hackish, is to complete the C API of cpyext in PyPy until it works
> well enough.  Don't come complaining "it's slow", though.  It *is*
> going to be slow.

My personal take on this is: if PyPy can't come up with a fast way to
interface with C code, it's bound to die. Certainly not right away, maybe
it'll find a niche somewhere to survive. Some applications simply don't
have native dependencies, at least not in the beginning. If it's really
lucky, there'll be enough people who rewrite their software and it may
still take the JVM path. But if it doesn't, well ...


More information about the pypy-dev mailing list