[pypy-svn] r52783 - pypy/dist/pypy/doc
cfbolz at codespeak.net
cfbolz at codespeak.net
Thu Mar 20 17:49:46 CET 2008
Author: cfbolz
Date: Thu Mar 20 17:49:46 2008
New Revision: 52783
Modified:
pypy/dist/pypy/doc/ctypes-implementation.txt
Log:
add articles, enhance a bit
Modified: pypy/dist/pypy/doc/ctypes-implementation.txt
==============================================================================
--- pypy/dist/pypy/doc/ctypes-implementation.txt (original)
+++ pypy/dist/pypy/doc/ctypes-implementation.txt Thu Mar 20 17:49:46 2008
@@ -8,26 +8,29 @@
* interpreter level code - code written in RPython, compiled
to something else, say C, part of the interpreter.
-PyPy's ctypes implementation is right now mostly proof of concept,
-based on idea of quick prototyping. The main idea was to use libffi
+PyPy's ctypes implementation is right now mostly a proof of concept,
+based on the idea of quick prototyping. The main idea was to use libffi
(same as CPython's ctypes implementation), but try to keep as much
-as possible in Python, not RPython. In cpython's situation, it would
-be to write as few as possible code in C.
+code as possible in Python, not RPython. In CPython's situation,
+the equivalent would be to write as little as possible code in C.
Low-level part (called \_rawffi)
================================
-We implemented direct bindings to libffi in RPython, allowing to create
-simple types (arrays, structures), leaving in C world, managed by hand.
-This part contains no special code to keep stuff alive and is kept
-to minimum possible.
+We implemented direct bindings to libffi in RPython, allowing to create simple
+types (arrays, structures), living in C world, managed by hand. It also
+supports calling C functions.
+This part contains no special code to keep objects alive and is kept very minimal.
+We tried to keep this as small as possible to allow porting our ctypes
+implementation to other platforms easily. It's also thinkable that Jython uses
+our ctypes implementation by writing their version of _rawffi.
High-level part (lib/\_ctypes)
===============================
-This part implements the same interface as \_ctypes module in CPython,
-but it's writte in full python. This approach allowed us to experiment
-quickly and provide working implementation in 2 months of real time.
+This part implements the same interface as the \_ctypes module in CPython,
+but it's written in full python. This approach allowed us to experiment
+quickly and provide a working implementation in 2 months of real time.
Reuse of the highest level (lib/ctypes)
========================================
@@ -45,9 +48,9 @@
Future
======
-Ctypes implementation in PyPy is pretty much working and can run for example
-pyglet. Because it's written in pure-python, it's rather slow. As a next
-step we'll measure what so costly and try to move certain parts from
+The Ctypes implementation in PyPy is pretty much working and can run for example
+pyglet. Because it's written in pure python, it's rather slow. As a next
+step we'll measure which parts are costly and try to move certain parts from
app-level to interp-level to improve speed. Still, we will try to keep
-interp-level part as simple as possible, not to loose robustness.
+interp-level part as simple as possible, to not loose robustness.
More information about the Pypy-commit
mailing list