Commit c4fa206b authored by William Stein's avatar William Stein

Initial version

This diff is collapsed.
The original Pyrex code as of 2006-04 is licensed under the following
license: "Copyright stuff: Pyrex is free of restrictions. You may use,
redistribute, modify and distribute modified versions."
Cython, which derives from Pyrex, is licensed under the Python
Software Foundation License. More precisely, all modifications
made to go from Pyrex to Cython are so licensed.
python build_ext --inplace
test: all
python 20
cd callback; $(MAKE) test
@echo Cleaning Demos
@rm -f *.c *.o *.so *~ core
@rm -rf build
@cd callback; $(MAKE) clean
@cd embed; $(MAKE) clean
PYHOME = $(HOME)/pkg/python/version
-I$(PYHOME)/include/python2.2 \
%.c: %.pyx
../bin/pyrexc $<
%.o: %.c
gcc -c -fPIC $(PYINCLUDE) $< %.o
gcc -shared $< -lm -o $@
@echo Cleaning Demos
@rm -f *.c *.o *.so *~ core core.*
@cd callback; $(MAKE) clean
@cd embed; $(MAKE) clean
from distutils.core import setup
from distutils.extension import Extension
from Pyrex.Distutils import build_ext
name = 'Demos',
Extension("primes", ["primes.pyx"]),
Extension("spam", ["spam.pyx"]),
Extension("numeric_demo", ["numeric_demo.pyx"]),
cmdclass = {'build_ext': build_ext}
python build_ext --inplace
test: all
@echo Cleaning Demos/callback
@rm -f cheese.c *.o *.so *~ core
@rm -rf build
PYHOME = $(HOME)/pkg/python/version
-I$(PYHOME)/include/python2.2 \
%.c: %.pyx
../../bin/pyrexc $<
%.o: %.c
gcc -c -fPIC $(PYINCLUDE) $< %.o
gcc -shared $< -lm -o $@
@echo Cleaning Demos/callback
@rm -f *.c *.o *.so *~ core core.*
This example demonstrates how you can wrap a C API that has a callback interface, so that you can pass Python functions to it as callbacks. The files cheesefinder.h and cheesefinder.c represent the C library to be wrapped. The file cheese.pyx is the Pyrex module which wraps it. The file demonstrates how to call the wrapper.
\ No newline at end of file
from distutils.core import setup
from distutils.extension import Extension
from Pyrex.Distutils import build_ext
name = 'callback',
Extension("cheese", ["cheese.pyx", "cheesefinder.c"]),
cmdclass = {'build_ext': build_ext}
# Pyrex wrapper for the cheesefinder API
cdef extern from "cheesefinder.h":
ctypedef void (*cheesefunc)(char *name, void *user_data)
void find_cheeses(cheesefunc user_func, void *user_data)
def find(f):
find_cheeses(callback, <void*>f)
cdef void callback(char *name, void *f):
* An example of a C API that provides a callback mechanism.
#include "cheesefinder.h"
static char *cheeses[] = {
"that runny one",
void find_cheeses(cheesefunc user_func, void *user_data) {
char **p = cheeses;
while (*p) {
user_func(*p, user_data);
typedef void (*cheesefunc)(char *name, void *user_data);void find_cheeses(cheesefunc user_func, void *user_data);
\ No newline at end of file
import cheese
def report_cheese(name):
print "Found cheese:", name
PYHOME = $(HOME)/pkg/python/$(PYVERSION)
-I$(PYHOME)/include/python$(PYVERSION) \
PYLIB = -L$(PYARCH)/lib/python$(PYVERSION)/config \
-lpython$(PYVERSION) \
-ldl -lpthread -lutil -lm
%.c: %.pyx
../../bin/pyrexc $<
%.o: %.c
gcc -c -fPIC $(PYINCLUDE) $< %.o
# gcc -shared $< -lm -o $@
all: main
main: main.o embedded.o
gcc main.o embedded.o $(PYLIB) -o main
@echo Cleaning Demos/embed
@rm -f *~ *.o *.so core core.* embedded.h embedded.c main
embedded.h: embedded.c
main.o: embedded.h
# Makefile for Microsoft C Compiler, building a DLL
CFLAGS = $(PYINCLUDE) /Ox /W3 /GX -nologo
.SUFFIXES: .exe .dll .obj .c .cpp .pyx
$(PYHOME)\Python.exe ../../ $<
all: main.exe
del /Q/F *.obj embedded.h embedded.c main.exe embedded.dll embedded.lib embedded.exp
# When linking the DLL we must explicitly list all of the exports
# There doesn't seem to be an easy way to get DL_EXPORT to have the correct definition
# to do the export for us without breaking the importing of symbols from the core
# python library.
embedded.dll: embedded.obj
link /nologo /DLL /INCREMENTAL:NO $(PYLIB) $** /IMPLIB:$*.lib /DEF:<< /OUT:$*.dll
EXPORTS initembedded
main.exe: main.obj embedded.lib
link /nologo $** $(PYLIB) /OUT:main.exe
embedded.h: embedded.c
main.obj: embedded.h
embedded.obj: embedded.c
$(CC) /MD $(CFLAGS) -c $**
embedded.lib: embedded.dll
# Makefile for Microsoft compiler statically linking PYVERSION = 2.2 PYHOME = \Python$(PYVERSION:.=) PYINCLUDE = -I$(PYHOME)\include PYLIB = /LIBPATH:$(PYHOME)\libs python22.lib CFLAGS = $(PYINCLUDE) /Ox /W3 /GX -nologo .SUFFIXES: .exe .dll .obj .c .cpp .pyx .pyx.c: $(PYHOME)\Python.exe ../../ $< all: main.exe clean: -del /Q/F *.obj embedded.h embedded.c main.exe main.exe: main.obj embedded.obj link /nologo $** $(PYLIB) /OUT:main.exe embedded.h: embedded.c main.obj: embedded.h
\ No newline at end of file
PYHOME = $(HOME)/pkg/python/$(PYVERSION)
-I$(PYHOME)/include/python$(PYVERSION) \
PYLIB = -L$(PYARCH)/lib/python$(PYVERSION)/config \
-lpython$(PYVERSION) \
-ldl -lpthread -lutil -lm
%.c: %.pyx
../../bin/pyrexc $<
%.o: %.c
gcc -c -fPIC $(PYINCLUDE) $< %.o
# gcc -shared $< -lm -o $@
all: main
main: main.o embedded.o
gcc main.o embedded.o $(PYLIB) -o main
@echo Cleaning Demos/embed
@rm -f *~ *.o *.so core core.* embedded.h embedded.c main
embedded.h: embedded.c
main.o: embedded.h
This example demonstrates how Pyrex-generated code can be called directly from a main program written in C. In this example, the module's initialisation function (called "initembedded", since the module is called "embedded") is called explicitly. This is necessary because the module is not being imported using the normal Python import mechanism. The Windows makefiles were contributed by Duncan Booth <>.
\ No newline at end of file
cdef public void spam():
def praise():
print "Spam, glorious spam!"
#include "Python.h"
#include "embedded.h"
int main(int argc, char *argv) {
# This example demonstrates how to access the internals
# of a Numeric array object.
cdef extern from "Numeric/arrayobject.h":
struct PyArray_Descr:
int type_num, elsize
char type
ctypedef class Numeric.ArrayType [object PyArrayObject]:
cdef char *data
cdef int nd
cdef int *dimensions, *strides
cdef object base
cdef PyArray_Descr *descr
cdef int flags
def print_2d_array(ArrayType a):
print "Type:", chr(a.descr.type)
if chr(a.descr.type) <> "f":
raise TypeError("Float array required")
if a.nd <> 2:
raise ValueError("2 dimensional array required")
cdef int nrows, ncols
cdef float *elems, x
nrows = a.dimensions[0]
ncols = a.dimensions[1]
elems = <float *>
hyphen = "-"
divider = ("+" + 10 * hyphen) * ncols + "+"
print divider
for row in range(nrows):
for col in range(ncols):
x = elems[row * ncols + col]
print "| %8f" % x,
print "|"
print divider
def primes(int kmax):
cdef int n, k, i
cdef int p[1000]
result = []
if kmax > 1000:
kmax = 1000
k = 0
n = 2
while k < kmax:
i = 0
while i < k and n % p[i] <> 0:
i = i + 1
if i == k:
p[k] = n
k = k + 1
n = n + 1
return result
def primes(kmax):
p = []
k = 0
n = 2
while k < kmax:
i = 0
while i < k and n % p[i] <> 0:
i = i + 1
if i == k:
k = k + 1
n = n + 1
return p
import Numeric
import numeric_demo
a = Numeric.array([[1.0, 3.5, 8.4], [2.3, 6.6, 4.1]], "f")
import sys
from primes import primes
if len(sys.argv) >= 2:
n = int(sys.argv[1])
n = 1000
print primes(n)
from spam import Spam
s = Spam()
print "Created:", s
print "Amount =", s.get_amount()
s = None
# Example of an extension type.
cdef class Spam:
cdef int amount
def __new__(self):
self.amount = 0
def __dealloc__(self):
print self.amount, "tons of spam is history."
def get_amount(self):
return self.amount
def set_amount(self, new_amount):
self.amount = new_amount
def describe(self):
print self.amount, "tons of spam!"
<!doctype html public "-//w3c//dtd html 4.0 transitional//en"><html><head> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> <meta name="GENERATOR" content="Mozilla/4.51 (Macintosh; I; PPC) [Netscape]"> <title>About Pyrex</title></head><body> <center><h1> <hr width="100%">Pyrex</h1></center> <center><i><font size=+1>A language for writing Python extension modules</font></i><hr width="100%"></center> <h2> What is Pyrex all about?</h2> Pyrex is a language specially designed for writing Python extension modules. It's designed to bridge the gap between the nice, high-level, easy-to-use world of Python and the messy, low-level world of C.<p>You may be wondering why anyone would want a special language for this. Python is really easy to extend using C or C++, isn't it? Why not just write your extension modules in one of those languages?<p>Well, if you've ever written an extension module for Python, you'll know that things are not as easy as all that. First of all, there is a fair bit of boilerplate code to write before you can even get off the ground. Then you're faced with the problem of converting between Python and C data types. For the basic types such as numbers and strings this is not too bad, but anything more elaborate and you're into picking Python objects apart using the Python/C API calls, which requires you to be meticulous about maintaining reference counts, checking for errors at every step and cleaning up properly if anything goes wrong. Any mistakes and you have a nasty crash that's very difficult to debug.<p>Various tools have been developed to ease some of the burdens of producing extension code, of which perhaps <a href="">SWIG</a> is the best known. SWIG takes a definition file consisting of a mixture of C code and specialised declarations, and produces an extension module. It writes all the boilerplate for you, and in many cases you can use it without knowing about the Python/C API. But you need to use API calls if any substantial restructuring of the data is required between Python and C.<p>What's more, SWIG gives you no help at all if you want to create a new built-in Python <i>type. </i>It will generate pure-Python classes which wrap (in a slightly unsafe manner) pointers to C data structures, but creation of true extension types is outside its scope.<p>Another notable attempt at making it easier to extend Python is <a href="">PyInline</a> , inspired by a similar facility for Perl. PyInline lets you embed pieces of C code in the midst of a Python file, and automatically extracts them and compiles them into an extension. But it only converts the basic types automatically, and as with SWIG,&nbsp; it doesn't address the creation of new Python types.<p>Pyrex aims to go far beyond what any of these previous tools provides. Pyrex deals with the basic types just as easily as SWIG, but it also lets you write code to convert between arbitrary Python data structures and arbitrary C data structures, in a simple and natural way, without knowing<i>anything</i> about the Python/C API. That's right -- <i>nothing at all</i>! Nor do you have to worry about reference counting or error checking -- it's all taken care of automatically, behind the scenes, just as it is in interpreted Python code. And what's more, Pyrex lets you define new<i>built-in</i> Python types just as easily as you can define new classes in Python.<p>Sound too good to be true? Read on and find out how it's done.<h2> The Basics of Pyrex</h2> The fundamental nature of Pyrex can be summed up as follows: <b>Pyrex is Python with C data types</b>.<p><i>Pyrex is Python:</i> Almost any piece of Python code is also valid Pyrex code. (There are a few limitations, but this approximation will serve for now.) The Pyrex compiler will convert it into C code which makes equivalent calls to the Python/C API. In this respect, Pyrex is similar to the former Python2C project (to which I would supply a reference except that it no longer seems to exist).<p><i>...with C data types.</i> But Pyrex is much more than that, because parameters and variables can be declared to have C data types. Code which manipulates Python values and C values can be freely intermixed, with conversions occurring automatically wherever possible. Reference count maintenance and error checking of Python operations is also automatic, and the full power of Python's exception handling facilities, including the try-except and try-finally statements, is available to you -- even in the midst of manipulating C data.<p>Here's a small example showing some of what can be done. It's a routine for finding prime numbers. You tell it how many primes you want, and it returns them as a Python list.<blockquote><b><tt><font size=+1>primes.pyx</font></tt></b></blockquote> <blockquote><pre>&nbsp;1&nbsp; def primes(int kmax):&nbsp;2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; cdef int n, k, i&nbsp;3&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; cdef int p[1000]&nbsp;4&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; result = []&nbsp;5&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if kmax > 1000:&nbsp;6&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; kmax = 1000&nbsp;7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; k = 0&nbsp;8&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; n = 2&nbsp;9&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; while k &lt; kmax: 10&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; i = 0 11&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; while i &lt; k and n % p[i] &lt;> 0: 12&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; i = i + 1 13&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if i == k: 14&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; p[k] = n 15&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; k = k + 1 16&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; result.append(n) 17&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; n = n + 1 18&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; return result</pre></blockquote> You'll see that it starts out just like a normal Python function definition, except that the parameter <b>kmax</b> is declared to be of type <b>int</b> . This means that the object passed will be converted to a C integer (or a TypeError will be raised if it can't be).<p>Lines 2 and 3 use the <b>cdef</b> statement to define some local C variables. Line 4 creates a Python list which will be used to return the result. You'll notice that this is done exactly the same way it would be in Python. Because the variable <b>result</b> hasn't been given a type, it is assumed to hold a Python object.<p>Lines 7-9 set up for a loop which will test candidate numbers for primeness until the required number of primes has been found. Lines 11-12, which try dividing a candidate by all the primes found so far, are of particular interest. Because no Python objects are referred to, the loop is translated entirely into C code, and thus runs very fast.<p>When a prime is found, lines 14-15 add it to the p array for fast access by the testing loop, and line 16 adds it to the result list. Again, you'll notice that line 16 looks very much like a Python statement, and in fact it is, with the twist that the C parameter <b>n</b> is automatically converted to a Python object before being passed to the <b>append</b> method. Finally, at line 18, a normal Python <b>return</b> statement returns the result list.<p>Compiling primes.pyx with the Pyrex compiler produces an extension module which we can try out in the interactive interpreter as follows:<blockquote><pre>>>> import primes >>> primes.primes(10) [2, 3, 5, 7, 11, 13, 17, 19, 23, 29] >>></pre></blockquote> See, it works! And if you're curious about how much work Pyrex has saved you, take a look at the <a href="primes.c">C code generated for this module</a> .<h2> Language Details</h2> For more about the Pyrex language, see the <a href="overview.html">Language Overview</a> .<h2> Future Plans</h2> Pyrex is not finished. Substantial tasks remaining include:<ul><li> Support for certain Python language features which are planned but not yet implemented. See the <a href="overview.html#Limitations">Limitations</a> section of the <a href="overview.html">Language Overview</a> for a current list.</li></ul> <ul><li> C++ support. This could be a very big can of worms - careful thought required before going there.</li></ul> <ul><li> Reading C/C++ header files directly would be very nice, but there are some severe problems that I will have to find solutions for first, such as what to do about preprocessor macros. My current thinking is to use a separate tool to convert .h files into Pyrex declarations, possibly with some manual intervention.</li></ul> </body></html>
\ No newline at end of file
<!DOCTYPE doctype PUBLIC "-//w3c//dtd html 4.0 transitional//en">
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="GENERATOR" content="Mozilla/4.51 (Macintosh; I; PPC) [Netscape]"><title>FAQ.html</title></head>
<center> <h1> <hr width="100%">Pyrex FAQ
<hr width="100%"></h1>
<h2> Contents</h2>
<li> <b><a href="#CallCAPI">How do I call Python/C API routines?</a></b></li>
<li> <b><a href="#NullBytes">How do I convert a C string containing null
bytes to a Python string?</a></b></li>
<li> <b><a href="#NumericAccess">How do I access the data inside a Numeric
array object?</a></b></li>
<li><b><a href="#Rhubarb">Pyrex says my extension type object has no attribute
'rhubarb', but I know it does. What gives?</a></b></li><li><a style="font-weight: bold;" href="#Quack">Python says my extension type has no method called 'quack', but I know it does. What gives?</a><br>
<hr width="100%"> <h2> <a name="CallCAPI"></a>How do I call Python/C API routines?</h2>
Declare them as C functions inside a <tt>cdef extern from</tt> block.
Use the type name <tt>object</tt> for any parameters and return types which
are Python object references. Don't use the word <tt>const</tt> anywhere.
Here is an example which defines and uses the <tt>PyString_FromStringAndSize</tt> routine:
<blockquote><tt>cdef extern from "Python.h":</tt> <br>
<tt>&nbsp;&nbsp;&nbsp; object PyString_FromStringAndSize(char *, int)</tt> <p><tt>cdef char buf[42]</tt> <br>
<tt>my_string = PyString_FromStringAndSize(buf, 42)</tt></p>
<h2> <a name="NullBytes"></a>How do I convert a C string containing null
bytes to a Python string?</h2>
Put in a declaration for the <tt>PyString_FromStringAndSize</tt> API routine
and use that<tt>.</tt> See <a href="#CallCAPI">How do I call Python/C API
routines?</a> <h2> <a name="NumericAccess"></a>How do I access the data inside a Numeric
array object?</h2>
Use a <tt>cdef extern from</tt> block to include the Numeric header file
and declare the array object as an external extension type. The following
code illustrates how to do this:
<blockquote><tt>cdef extern from "Numeric/arrayobject.h":</tt> <p><tt>&nbsp;&nbsp;&nbsp; struct PyArray_Descr:</tt> <br>
<tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; int type_num, elsize</tt> <br>
<tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; char type</tt> </p>
<p><tt>&nbsp;&nbsp;&nbsp; ctypedef class Numeric.ArrayType [object PyArrayObject]</tt><tt>:</tt> <br>
<tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; cdef char *data</tt> <br>
<tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; cdef int nd</tt> <br>
<tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; cdef int *dimensions,
*strides</tt> <br>
<tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; cdef object base</tt>
<tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; cdef PyArray_Descr *descr</tt> <br>
<tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; cdef int flags<br>
<p>For more information about external extension types, see the <a href="extension_types.html#ExternalExtTypes">"External Extension Types"</a>
section of the <a href="extension_types.html">"Extension Types"</a> documentation
<tt> </tt> </p>
<h2><a name="Rhubarb"></a>Pyrex says my extension type object has no attribute
'rhubarb', but I know it does. What gives?</h2>
You're probably trying to access it through a reference which Pyrex thinks
is a generic Python object. You need to tell Pyrex that it's a reference
to your extension type by means of a declaration,<br>
for example,<br>
<blockquote><tt>cdef class Vegetables:</tt><br>
<tt>&nbsp; &nbsp; cdef int rhubarb</tt><br>
<tt>cdef Vegetables veg</tt><br>
<tt>veg.rhubarb = 42</tt><br>
Also see the <a href="extension_types.html#ExtTypeAttrs">"Attributes"</a>
section of the <a href="extension_types.html">"Extension
Types"</a> documentation page.<br>
<h2><a name="Quack"></a>Python says my extension type has no method called 'quack', but I know it does. What gives?</h2>
You may have declared the method using <span style="font-family: monospace;">cdef</span> instead of <span style="font-family: monospace;">def</span>. Only functions and methods declared with <span style="font-family: monospace;">def</span> are callable from Python code.<br>
\ No newline at end of file
This diff is collapsed.
<!doctype html public "-//w3c//dtd html 4.0 transitional//en"><html><head> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> <meta name="GENERATOR" content="Mozilla/4.51 (Macintosh; I; PPC) [Netscape]"> <title>Pyrex - Front Page</title></head><body>&nbsp;<table CELLSPACING=0 CELLPADDING=10 WIDTH="500" ><tr><td VALIGN=TOP BGCOLOR="#FF9218"><font face="Arial,Helvetica"><font size=+4>Pyrex</font></font></td> <td ALIGN=RIGHT VALIGN=TOP WIDTH="200" BGCOLOR="#5DBACA"><font face="Arial,Helvetica"><font size=+1>A smooth blend of the finest Python&nbsp;</font></font><br><font face="Arial,Helvetica"><font size=+1>with the unsurpassed power&nbsp;</font></font><br><font face="Arial,Helvetica"><font size=+1>of raw C.</font></font></td></tr></table> <blockquote><font size=+1>Welcome to Pyrex, a language for writing Python extension modules. Pyrex makes creating an extension module is almost as easy as creating a Python module! To find out more, consult one of the edifying documents below.</font></blockquote> <h1><font face="Arial,Helvetica"><font size=+2>Documentation</font></font></h1> <blockquote><h2><font face="Arial,Helvetica"><font size=+1><a href="About.html">About Pyrex</a></font></font></h2> <blockquote><font size=+1>Read this to find out what Pyrex is all about and what it can do for you.</font></blockquote> <h2><font face="Arial,Helvetica"><font size=+1><a href="overview.html">Language Overview</a></font></font></h2> <blockquote><font size=+1>A description of all the features of the Pyrex language. This is the closest thing to a reference manual in existence yet.</font></blockquote> <h2><font face="Arial,Helvetica"><font size=+1><a href="FAQ.html">FAQ</a></font></font></h2> <blockquote><font size=+1>Want to know how to do something in Pyrex? Check here first<font face="Arial,Helvetica">.</font></font></blockquote></blockquote> <h1><font face="Arial,Helvetica"><font size=+2>Other Resources</font></font></h1> <blockquote><h2><font face="Arial,Helvetica"><font size=+1><a href="">Michael's Quick Guide to Pyrex</a></font></font></h2> <blockquote><font size=+1>This tutorial-style presentation will take you through the steps of creating some Pyrex modules to wrap existing C libraries. Contributed by <a href="">Michael JasonSmith</a>.</font></blockquote> <h2><font face="Arial,Helvetica"><font size=+1><a href="">Mail to the Author</a></font></font></h2> <blockquote><font size=+1>If you have a question that's not answered by anything here, you're not sure about something, or you have a bug to report or a suggestion to make, or anything at all to say about Pyrex, feel free to email me:<font face="Arial,Helvetica"> </font><tt><a href=""></a></tt></font></blockquote></blockquote> </body></html>
\ No newline at end of file
This diff is collapsed.
#include "Python.h" static PyObject *__Pyx_UnpackItem(PyObject *, int); static int __Pyx_EndUnpack(PyObject *, int); static int __Pyx_PrintItem(PyObject *); static int __Pyx_PrintNewline(void); static void __Pyx_ReRaise(void); static void __Pyx_RaiseWithTraceback(PyObject *, PyObject *, PyObject *); static PyObject *__Pyx_Import(PyObject *name, PyObject *from_list); static PyObject *__Pyx_GetExcValue(void); static PyObject *__Pyx_GetName(PyObject *dict, char *name); static PyObject *__pyx_m; static PyObject *__pyx_d; static PyObject *__pyx_b; PyObject *__pyx_f_primes(PyObject *__pyx_self, PyObject *__pyx_args); /*proto*/ PyObject *__pyx_f_primes(PyObject *__pyx_self, PyObject *__pyx_args) { int __pyx_v_kmax; int __pyx_v_n; int __pyx_v_k; int __pyx_v_i; int (__pyx_v_p[1000]); PyObject *__pyx_v_result; PyObject *__pyx_r; PyObject *__pyx_1 = 0; int __pyx_2; int __pyx_3; int __pyx_4; PyObject *__pyx_5 = 0; PyObject *__pyx_6 = 0; if (!PyArg_ParseTuple(__pyx_args, "i", &__pyx_v_kmax)) return 0; __pyx_v_result = Py_None; Py_INCREF(__pyx_v_result); /* "ProjectsA:Python:Pyrex:Demos:primes.pyx":2 */ /* "ProjectsA:Python:Pyrex:Demos:primes.pyx":3 */ /* "ProjectsA:Python:Pyrex:Demos:primes.pyx":4 */ __pyx_1 = PyList_New(0); if (!__pyx_1) goto __pyx_L1; Py_DECREF(__pyx_v_result); __pyx_v_result = __pyx_1; __pyx_1 = 0; /* "ProjectsA:Python:Pyrex:Demos:primes.pyx":5 */ __pyx_2 = (__pyx_v_kmax > 1000); if (__pyx_2) { /* "ProjectsA:Python:Pyrex:Demos:primes.pyx":6 */ __pyx_v_kmax = 1000; goto __pyx_L2; } __pyx_L2:; /* "ProjectsA:Python:Pyrex:Demos:primes.pyx":7 */ __pyx_v_k = 0; /* "ProjectsA:Python:Pyrex:Demos:primes.pyx":8 */ __pyx_v_n = 2; /* "ProjectsA:Python:Pyrex:Demos:primes.pyx":9 */ while (1) { __pyx_L3:; __pyx_2 = (__pyx_v_k < __pyx_v_kmax); if (!__pyx_2) break; /* "ProjectsA:Python:Pyrex:Demos:primes.pyx":10 */ __pyx_v_i = 0; /* "ProjectsA:Python:Pyrex:Demos:primes.pyx":11 */ while (1) { __pyx_L5:; if (__pyx_3 = (__pyx_v_i < __pyx_v_k)) { __pyx_3 = ((__pyx_v_n % (__pyx_v_p[__pyx_v_i])) != 0); } if (!__pyx_3) break; /* "ProjectsA:Python:Pyrex:Demos:primes.pyx":12 */ __pyx_v_i = (__pyx_v_i + 1); } __pyx_L6:; /* "ProjectsA:Python:Pyrex:Demos:primes.pyx":13 */ __pyx_4 = (__pyx_v_i == __pyx_v_k); if (__pyx_4) { /* "ProjectsA:Python:Pyrex:Demos:primes.pyx":14 */ (__pyx_v_p[__pyx_v_k]) = __pyx_v_n; /* "ProjectsA:Python:Pyrex:Demos:primes.pyx":15 */ __pyx_v_k = (__pyx_v_k + 1); /* "ProjectsA:Python:Pyrex:Demos:primes.pyx":16 */ __pyx_1 = PyObject_GetAttrString(__pyx_v_result, "append"); if (!__pyx_1) goto __pyx_L1; __pyx_5 = PyInt_FromLong(__pyx_v_n); if (!__pyx_5) goto __pyx_L1; __pyx_6 = PyTuple_New(1); if (!__pyx_6) goto __pyx_L1; PyTuple_SET_ITEM(__pyx_6, 0, __pyx_5); __pyx_5 = 0; __pyx_5 = PyObject_CallObject(__pyx_1, __pyx_6); if (!__pyx_5) goto __pyx_L1; Py_DECREF(__pyx_6); __pyx_6 = 0; Py_DECREF(__pyx_5); __pyx_5 = 0; goto __pyx_L7; } __pyx_L7:; /* "ProjectsA:Python:Pyrex:Demos:primes.pyx":17 */ __pyx_v_n = (__pyx_v_n + 1); } __pyx_L4:; /* "ProjectsA:Python:Pyrex:Demos:primes.pyx":18 */ Py_INCREF(__pyx_v_result); __pyx_r = __pyx_v_result; goto __pyx_L0; __pyx_r = Py_None; Py_INCREF(__pyx_r); goto __pyx_L0; __pyx_L1:; Py_XDECREF(__pyx_1); Py_XDECREF(__pyx_5); Py_XDECREF(__pyx_6); __pyx_r = 0; __pyx_L0:; Py_DECREF(__pyx_v_result); return __pyx_r; } static struct PyMethodDef __pyx_methods[] = { {"primes", (PyCFunction)__pyx_f_primes, METH_VARARGS, 0}, {0, 0, 0, 0} }; void initprimes(void); /*proto*/ void initprimes(void) { __pyx_m = Py_InitModule4("primes", __pyx_methods, 0, 0, PYTHON_API_VERSION); __pyx_d = PyModule_GetDict(__pyx_m); __pyx_b = PyImport_AddModule("__builtin__"); PyDict_SetItemString(__pyx_d, "__builtins__", __pyx_b); }/* Runtime support code */
\ No newline at end of file
This diff is collapsed.
This diff is collapsed.
Pyrex - Installation Instructions
You have two installation options:
(1) Run the script in this directory
as follows:
python install
This will install the Pyrex package
into your Python system.
(2) If you prefer not to modify your Python
installation, arrange for the directory
containing this file (INSTALL.txt) to be in
your PYTHONPATH. On unix, also put the bin
directory on your PATH.
See README.txt for pointers to other documentation.
1. This LICENSE AGREEMENT is between the Python Software Foundation
("PSF"), and the Individual or Organization ("Licensee") accessing and
otherwise using Python 2.4 software in source or binary form and its
associated documentation.
2. Subject to the terms and conditions of this License Agreement, PSF
hereby grants Licensee a nonexclusive, royalty-free, world-wide
license to reproduce, analyze, test, perform and/or display publicly,
prepare derivative works, distribute, and otherwise use Python 2.4
alone or in any derivative version, provided, however, that PSF's
License Agreement and PSF's notice of copyright, i.e., "Copyright (c)
2001, 2002, 2003, 2004 Python Software Foundation; All Rights Reserved"
are retained in Python 2.4 alone or in any derivative version prepared
by Licensee.
3. In the event Licensee prepares a derivative work that is based on
or incorporates Python 2.4 or any part thereof, and wants to make
the derivative work available to others as provided herein, then
Licensee hereby agrees to include in any such work a brief summary of
the changes made to Python 2.4.
4. PSF is making Python 2.4 available to Licensee on an "AS IS"
6. This License Agreement will automatically terminate upon a material
breach of its terms and conditions.
7. Nothing in this License Agreement shall be deemed to create any
relationship of agency, partnership, or joint venture between PSF and
Licensee. This License Agreement does not grant permission to use PSF
trademarks or trade name in a trademark sense to endorse or promote
products or services of Licensee, or any third party.
8. By copying, installing or otherwise using Python 2.4, Licensee
agrees to be bound by the terms and conditions of this License
include README.txt INSTALL.txt CHANGES.txt ToDo.txt USAGE.txt
include bin/pyrexc
include Pyrex/Compiler/Lexicon.pickle
include Doc/*
include Demos/*
@echo "Setting version to $(VERSION)"
@echo "version = '$(VERSION)'" > Pyrex/Compiler/
# @if [ ! -d Pyrex/Distutils ]; then \
# echo Pyrex/Distutils missing; \
# exit 1; \
# fi
@echo Cleaning Source
@rm -f *.pyc */*.pyc */*/*.pyc
@rm -f *~ */*~ */*/*~
@rm -f core */core
@(cd Demos; $(MAKE) clean)
Welcome to Cython!
Cython ( is based on Pyrex, but
supports more cutting edge functionality and optimizations.
The original Pyrex program was licensed "free of restrictions" (see
below). Cython itself is licensed under the
To see the change history, go to the Pyrex directory and type
$ hg log
This requires that you have installed Mercurial.
-- William Stein (
The following is from Pyrex:
This is a development version of Pyrex, a language
for writing Python extension modules.
For more info, see:
Doc/About.html for a description of the language
INSTALL.txt for installation instructions
USAGE.txt for usage instructions
Demos for usage examples
Comments, suggestions, bug reports, etc. are
Copyright stuff: Pyrex is free of restrictions. You
may use, redistribute, modify and distribute modified
The latest version of Pyrex can be found here:
Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | +--------------------------------------+
DONE - Pointer-to-function types.
DONE - Nested declarators.
DONE - Varargs C func defs and calls.
DONE - * and ** args in Python func defs.
DONE - Default argument values.
DONE - Tracebacks.
DONE - Disallow creating char * from Python temporary anywhere
(not just on assignment).
DONE - Module and function and class doc strings.
DONE - Predeclare C functions.
DONE - Constant expressions.
DONE - Forward C struct declarations.
DONE - Prefix & operator.
DONE - Get rid of auto string->char coercion and
add a c'X' syntax for char literals.
DONE - Cascaded assignments (a = b = c).
DONE - 'include' statement for including other Pyrex files.
DONE - Add command line option for specifying name of generated C file.
DONE - Add 'else' clause to try-except.
DONE - Allow extension types to be declared "public" so they
can be accessed from another Pyrex module or a C file.
DONE - Don't try to generate objstruct definition for external
extension type declared without suite (treat as though
declared with empty suite).
DONE - Implement two-argument form of 'assert' statement.
Const types.
Tuple/list construction: Evaluate & store items one at a time?
Varargs argument traversal.
Use PyDict_SetItemString to build keyword arg dicts?
(Or wait until names are interned.)
Intern names.
print >>file
abs() and anything similar.
Semicolon-separated statement lists.
Optional semicolons after C declarations.
Multiple C declarations on one line?
Optimise return without value outside of try-finally.
exec statement.
from ... import statement.
Use iterator protocol for unpacking.
Save & restore exception being handled on function entry/exit.
In-place operators (+=, etc).
Constant declarations. Syntax?