Merge pull request #2160 from gabrieldemarmiesse/pretty_rst

Made other readmes pretty for github.

Demos/Readme_demos.rst → Demos/README.rst

-* To run demos do::
+To run demos do::
 
     cd Demos
     make test
 
-  which runs run_primes.py, run_numeric_demo.py, run_spam.py,
-  integrate_timing.py, callback/runcheese.py and embed/embedded
+which runs ``run_primes.py``, ``run_numeric_demo.py``, ``run_spam.py``,
+``integrate_timing.py``, ``callback/runcheese.py`` and ``embed/embedded``
 
-* For other demos::
+For other demos::
 
     cd libraries
     python setup.py build_ext --inplace
     python -c 'import call_mymath;print(call_mymath.call_sinc(1))'
 
-  To run one of the benchmarks for 10 iterations to compare cython and python timings::
+To run one of the benchmarks for 10 iterations to compare cython and python timings::
 
     cd benchmarks
     python setup.py build_ext --inplace
     python nqueens.py -n 10
     python -c 'import nqueens;print(nqueens.test_n_queens(10))'
 
-  To demo cython/bin/cython_freeze::
+To demo ``cython/bin/cython_freeze``::
 
     make
     ./nCr 10 5

Demos/callback/README.txt → Demos/callback/README.rst

@@ -2,11 +2,11 @@ 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
+The files ``cheesefinder.h`` and ``cheesefinder.c``
 represent the C library to be wrapped.
 
-The file cheese.pyx is the Pyrex module
+The file ``cheese.pyx`` is the Cython module
 which wraps it.
 
-The file run_cheese.py demonstrates how to
+The file ``run_cheese.py`` demonstrates how to
 call the wrapper.

Demos/embed/README → Demos/embed/README.rst

@@ -2,4 +2,4 @@ This example demonstrates how Cython-generated code
 can be called directly from a main program written in C.
 
 The Windows makefiles were contributed by
-Duncan Booth <Duncan.Booth@SuttonCourtenay.org.uk>.
+Duncan Booth: Duncan.Booth@SuttonCourtenay.org.uk.

Demos/freeze/README.txt → Demos/freeze/README.rst

 NAME
 ====
 
-cython_freeze - create a C file for embedding Cython modules
+**cython_freeze** - create a C file for embedding Cython modules
 
 
 SYNOPSIS
 ========
+::
 
-cython_freeze [-o outfile] [-p] module [...]
+    cython_freeze [-o outfile] [-p] module [...]
 
 
 DESCRIPTION
@@ -32,21 +33,20 @@ modules, but it requires another C source file to be created.
 
 OPTIONS
 =======
+::
 
--o FILE, --outfile=FILE   write output to FILE instead of standard output
--p, --pymain              do not automatically run the first module as __main__
+    -o FILE, --outfile=FILE   write output to FILE instead of standard output
+    -p, --pymain              do not automatically run the first module as __main__
 
 
 EXAMPLE
 =======
 
-In the Demos/freeze directory, there exist two Cython modules:
+In the ``Demos/freeze`` directory, there exist two Cython modules:
 
-lcmath.pyx
-    A module that interfaces with the -lm library.
+* ``lcmath.pyx``: A module that interfaces with the -lm library.
 
-combinatorics.pyx
-    A module that implements n-choose-r using lcmath.
+* ``combinatorics.pyx``: A module that implements n-choose-r using lcmath.
 
 Both modules have the Python idiom ``if __name__ == "__main__"``, which only
 execute if that module is the "main" module.  If run as main, lcmath prints the

bin/cython_freeze

@@ -3,7 +3,7 @@
 Create a C file for embedding one or more Cython source files.
 Requires Cython 0.11.2 (or perhaps newer).
 
-See Demos/freeze/README.txt for more details.
+See Demos/freeze/README.rst for more details.
 """
 from __future__ import print_function
 

pyximport/README → pyximport/README.rst

- == Pyximport ==
+Pyximport
+=========
 
-Download: pyx-import-1.0.tar.gz
-<http://www.prescod.net/pyximport/pyximport-1.0.tar.gz>
-
-Pyrex is a compiler. Therefore it is natural that people tend to go
-through an edit/compile/test cycle with Pyrex modules. But my personal
+Cython is a compiler. Therefore it is natural that people tend to go
+through an edit/compile/test cycle with Cython modules. But my personal
 opinion is that one of the deep insights in Python's implementation is
 that a language can be compiled (Python modules are compiled to .pyc)
 files and hide that compilation process from the end-user so that they
-do not have to worry about it. Pyximport does this for Pyrex modules.
-For instance if you write a Pyrex module called "foo.pyx", with
-Pyximport you can import it in a regular Python module like this:
-
+do not have to worry about it. Pyximport does this for Cython modules.
+For instance if you write a Cython module called ``foo.pyx``, with
+Pyximport you can import it in a regular Python module like this::
 
-import pyximport; pyximport.install()
-import foo
+    import pyximport; pyximport.install()
+    import foo
 
-Doing so will result in the compilation of foo.pyx (with appropriate
+Doing so will result in the compilation of ``foo.pyx`` (with appropriate
 exceptions if it has an error in it).
 
-If you would always like to import pyrex files without building them
+If you would always like to import Cython files without building them
 specially, you can also add the first line above to your sitecustomize.py.
 That will install the hook every time you run Python. Then you can use
-Pyrex modules just with simple import statements. I like to test my
-Pyrex modules like this:
+Cython modules just with simple import statements. I like to test my
+Cython modules like this::
 
-
-python -c "import foo"
+    python -c "import foo"
 
 See help(pyximport.install) to learn its options for controlling the
-default behavior of "import" and "reload".
+default behavior of ``import`` and ``reload``.
 
- == Dependency Handling ==
+Dependency Handling
+-------------------
 
 In Pyximport 1.1 it is possible to declare that your module depends on
-multiple files, (likely ".h" and ".pxd" files). If your Pyrex module is
-named "foo" and thus has the filename "foo.pyx" then you should make
-another file in the same directory called "foo.pyxdep". The
-"modname.pyxdep" file can be a list of filenames or "globs" (like
-"*.pxd" or "include/*.h"). Each filename or glob must be on a separate
+multiple files, (likely ``.h`` and ``.pxd`` files). If your Cython module is
+named ``foo`` and thus has the filename ``foo.pyx`` then you should make
+another file in the same directory called ``foo.pyxdep``. The
+``modname.pyxdep`` file can be a list of filenames or ``globs`` (like
+``*.pxd`` or ``include/*.h``). Each filename or glob must be on a separate
 line. Pyximport will check the file date for each of those files before
 deciding whether to rebuild the module. In order to keep track of the
 fact that the dependency has been handled, Pyximport updates the
-modification time of your ".pyx" source file. Future versions may do
+modification time of your ``.pyx`` source file. Future versions may do
 something more sophisticated like informing distutils of the
 dependencies directly.
 
- == Limitations ==
-
-Pyximport does not give you any control over how your Pyrex file is
+Limitations
+-----------
+Pyximport does not give you any control over how your Cython file is
 compiled. Usually the defaults are fine. You might run into problems if
-you wanted to write your program in half-C, half-Pyrex and build them
+you wanted to write your program in half-C, half-Cython and build them
 into a single library. Pyximport 1.2 will probably do this.
 
 Pyximport does not hide the Distutils/GCC warnings and errors generated
@@ -59,15 +56,16 @@ something went wrong and why. And if nothing went wrong it will give you
 the warm fuzzy that pyximport really did rebuild your module as it was
 supposed to.
 
- == For further thought and discussion ==
+For further thought and discussion
+----------------------------------
 
-"setup.py install" does not modify sitecustomize.py for you. Should it?
+``setup.py install`` does not modify ``sitecustomize.py`` for you. Should it?
 Modifying Python's "standard interpreter" behaviour may be more than
 most people expect of a package they install..
 
-Pyximport puts your ".c" file beside your ".pyx" file (analogous to
-".pyc" beside ".py"). But it puts the platform-specific binary in a
+Pyximport puts your ``.c`` file beside your ``.pyx`` file (analogous to
+``.pyc`` beside ``.py``). But it puts the platform-specific binary in a
 build directory as per normal for Distutils. If I could wave a magic
-wand and get Pyrex or distutils or whoever to put the build directory I
+wand and get Cython or distutils or whoever to put the build directory I
 might do it but not necessarily: having it at the top level is VERY
-HELPFUL for debugging Pyrex problems.
+HELPFUL for debugging Cython problems.