summaryrefslogtreecommitdiffstats
path: root/debian/pyrex/pyrex-0.9.9/Doc/About.html
diff options
context:
space:
mode:
Diffstat (limited to 'debian/pyrex/pyrex-0.9.9/Doc/About.html')
-rw-r--r--debian/pyrex/pyrex-0.9.9/Doc/About.html149
1 files changed, 0 insertions, 149 deletions
diff --git a/debian/pyrex/pyrex-0.9.9/Doc/About.html b/debian/pyrex/pyrex-0.9.9/Doc/About.html
deleted file mode 100644
index 373625aa..00000000
--- a/debian/pyrex/pyrex-0.9.9/Doc/About.html
+++ /dev/null
@@ -1,149 +0,0 @@
-<!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><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><p>Various tools have been developed to ease some of the burdens of producing
-extension code, of which perhaps <a href="http://www.swig.org">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><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><p>Another notable attempt at making it easier to extend Python is <a href="http://pyinline.sourceforge.net/">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><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><p>Sound too good to be true? Read on and find out how it's done.
-</p><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><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><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.
-</p><blockquote><b><tt><font size="+1">primes.pyx</font></tt></b></blockquote>
-
-<blockquote>
-<pre>&nbsp;1&nbsp; def primes(int kmax):<br>&nbsp;2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; cdef int n, k, i<br>&nbsp;3&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; cdef int p[1000]<br>&nbsp;4&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; result = []<br>&nbsp;5&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if kmax &gt; 1000:<br>&nbsp;6&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; kmax = 1000<br>&nbsp;7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; k = 0<br>&nbsp;8&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; n = 2<br>&nbsp;9&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; while k &lt; kmax:<br>10&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; i = 0<br>11&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; while i &lt; k and n % p[i] &lt;&gt; 0:<br>12&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; i = i + 1<br>13&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if i == k:<br>14&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; p[k] = n<br>15&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; k = k + 1<br>16&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; result.append(n)<br>17&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; n = n + 1<br>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><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><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><p>Compiling primes.pyx with the Pyrex compiler produces an extension module
-which we can try out in the interactive interpreter as follows:
-</p><blockquote>
-<pre>&gt;&gt;&gt; import primes<br>&gt;&gt;&gt; primes.primes(10)<br>[2, 3, 5, 7, 11, 13, 17, 19, 23, 29]<br>&gt;&gt;&gt;</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="LanguageOverview.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="Manual/Limitations.html">Limitations</a>
-section of the <a href="LanguageOverview.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