[pypy-dev] Why CFFI is not useful - need direct ABI access 4 humans
Kenny Lasse Hoff Levinsen
kennylevinsen at gmail.com
Sun Mar 30 13:40:28 CEST 2014
Okay, just to get things right: What you want is an only-ABI solution, which abstracts completely away from technical details, in a nice pythonic wrapper?
Having that idea suggestion is fine (although it is slightly off-topic on pypy-dev), but it has nothing to do with the C Foreign Function Interface (CFFI), which is C-centric as it focuses on interfacing with C. It allows for making very easy interfaces to C with very little code, which as nice bonus also appears very clean.
One can also easily make the argument that, when you're glueing two languages together, you have to know both to make the proper considerations about their use. You risk making improper use of returned memory if you don't know what's going on, and you'll have no clue how to debug it.
But to sum it up:
- You want a language independent ABI interface that looks completely pythonic from the users point of view, and requires no knowledge of other languages
- This has nothing to do with CFFI, which is very specifically - as the name implies - a C interface, which does it's job very well.
My personal opinion of the idea is that it is likely to be troublesome enough to be unfeasible and very unpleasant to code. I also find it unlikely to work (without giving a load of trouble to the user), but that should not stop interested parties from trying.
P.S.: Calling the work of others useless is a bad way to introduce an idea. (Unless it's an idea for "How to be hated for Dummies")
> On 30/03/2014, at 11.05, anatoly techtonik <techtonik at gmail.com> wrote:
> On Sat, Mar 29, 2014 at 3:58 PM, Markus Unterwaditzer
> <markus at unterwaditzer.net> wrote:
>> On Sat, Mar 29, 2014 at 02:49:00PM +0300, anatoly techtonik wrote:
>>> I know what C in CFFI stands for C way of doing things, so
>>> I hope people won't try to defend that position and instead
>>> try to think about what if we have to re-engineer ABI access
>>> from scratch, for explicit and obvious debug binary interface.
>>> CFFI is not useful for Python programmers and here is why.
>>> The primary reason is that it requires you to know C.
>> You're using C if you're calling it from Python. Knowing the language (to some
>> degree) when using it is inevitable.
> This is the problem that I've tried to describe:
> All standard Python tools for ABI level access require C knowledge.
>>> And knowing C requires you to know about OS architecture.
>> The PyPy team (especially fijal) has always strongly discouraged from
>> porting Python code to C for performance. If you have a good reason to use C,
>> it is not surprising that you're going to be confronted with the dangers of
>> such a language. I am not sure if you're trying to make a point against C or
>> CFFI here.
> Against C. As I said, CFFI is good, but not enough to work conveniently with
> binary interfaces, and the reason for that is that it is C-centric.
> I support fijal - my position is that rewriting the same code in faster language
> is not a way to solve performance problems. Language as a problem is a
> failed smoke test for app architecture.
>> I am also not sure if the rest of your post actually means anything, or if it
>> is just way above my head. But given that you're throwing around with
>> statements like "this is useless", i don't feel compelled or motivated to try
>> to understand your ramblings.
> Fair point. Thanks for the feedback. Sometimes I feel like I should just stop
> wasting my time on ideas, and start eating some pills so that I could better
> concentrate on a mindless coding.
> anatoly t.
> pypy-dev mailing list
> pypy-dev at python.org
More information about the pypy-dev