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

[Maciej Fijalkowski]

On Tue, Feb 14, 2012 at 7:24 PM, Stefan Behnel <stefan_ml at behnel.de> wrote:
> 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 ...
>
> Stefan

Stefan, you're completely missing armin's point.

PyPy has a good way to interface with C. You can call C from RPython
using rffi and you can use ctypes. Both are not ideal for different
reasons, but we're addressing both of them in some mid-term and we
understand the need to interface with C.

What we *don't* buy is that interfacing with C, efficient and
convinient, requires you to have a stable C API that exposes objects.
Even more, we don't buy that the CPython C API is the best choice
here, even if you decide to have a C API. Instead we want to provide a
decent and performant FFI or a way to write modules in RPython.

That's why consider CPython C API mostly a legacy thing and not our way forward.

Cheers,
fijal