On Tue, Feb 14, 2012 at 7:24 PM, Stefan Behnel <stefan...@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 _______________________________________________ pypy-dev mailing list pypy-dev@python.org http://mail.python.org/mailman/listinfo/pypy-dev
