[pypy-dev] Why CFFI is not useful - need direct ABI access 4 humans
techtonik at gmail.com
Sun Mar 30 14:36:08 CEST 2014
On Sun, Mar 30, 2014 at 2:40 PM, Kenny Lasse Hoff Levinsen
<kennylevinsen at gmail.com> wrote:
> 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?
Not really. I want a language independent ABI solution, yes. ABI-only
implies that there is some alternative to that. I don't see any
alternative - for me ABI is the necessary basis for everything else on
top. So doing ABI solution design without considering these use cases
is impossible. I want a decoupled ABI level.
Nice pythonic wrapper that abstracts completely from technical details
is not the goal. The goal is to provide practical defaults for
language and hardware independent abstraction. The primary object that
abstraction should work with is "platform-independent binary data",
the method is "to be readable by humans". On implementation level that
means that by default there is no ambiguity in syntax that defines
binary data (size or endianness), and if there is a dependency on
platform (CPU bitness etc.) it should be explicit, so that the
behavior of structure should be clear (self-describing type names +
type docs that list relevant platforms and effects on every platform).
This approach inverts existing practice of using platform dependent
binary structures by default.
> 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
Exactly. Python here means "intuitive and user-friendly" (which may
appear different than indentations or YAML).
> - 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.
Yes CFFI does a perfect job on API level - I can't think of a better
way to provide access to C API other than with C syntax.
On ABI level tools can be more useful, and there is where idea
intersects with CFFI. It doesn't cancel the fact that people need safe
feet injury prevention interfaces. Look for my previous answer with
the phrase "I mix C with binary manipulation" that covers this.
> 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.
Ack. Thanks for the feedback.
More information about the pypy-dev