Skip to content
Snippets Groups Projects
Commit d02a33073bf2 authored by gabrieldemarmiesse's avatar gabrieldemarmiesse
Browse files

Changed some filenames.

parent 807db2224805
Branches
No related tags found
No related merge requests found
Show whitespace changes
Inline Side-by-side
Showing
with 235 additions and 237 deletions
Demos/README.rst 0 → 100644
+ 35
− 0
View file @ d02a3307
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``
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::
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``::
make
./nCr 10 5
./python
* Build notes
* benchmarks/chaos.py requires cython 0.24 or newer
* embed and freeze work for python2, require cython 0.24 or higher
for python 3.5
Demos/Readme_demos.rst deleted 100644 → 0
+ 0
− 35
View file @ 807db222
* 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
* 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::
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::
make
./nCr 10 5
./python
* Build notes
* benchmarks/chaos.py requires cython 0.24 or newer
* embed and freeze work for python2, require cython 0.24 or higher
for python 3.5
Demos/callback/README.rst 0 → 100644
+ 12
− 0
View file @ d02a3307
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 Cython module
which wraps it.
The file ``run_cheese.py`` demonstrates how to
call the wrapper.
Demos/callback/README.txt deleted 100644 → 0
+ 0
− 12
View file @ 807db222
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 run_cheese.py demonstrates how to
call the wrapper.
Demos/embed/README deleted 100644 → 0
+ 0
− 5
View file @ 807db222
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>.
Demos/embed/README.rst 0 → 100644
+ 5
− 0
View file @ d02a3307
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.
Demos/freeze/README.rst 0 → 100644
+ 111
− 0
View file @ d02a3307
NAME
====
**cython_freeze** - create a C file for embedding Cython modules
SYNOPSIS
========
::
cython_freeze [-o outfile] [-p] module [...]
DESCRIPTION
===========
**cython_freeze** generates a C source file to embed a Python interpreter
with one or more Cython modules built in. This allows one to create a single
executable from Cython code, without having to have separate shared objects
for each Cython module. A major advantage of this approach is that it allows
debugging with gprof(1), which does not work with shared objects.
Unless ``-p`` is given, the first module's ``__name__`` is set to
``"__main__"`` and is imported on startup; if ``-p`` is given, a normal Python
interpreter is built, with the given modules built into the binary.
Note that this method differs from ``cython --embed``. The ``--embed`` options
modifies the resulting C source file to include a ``main()`` function, so it
can only be used on a single Cython module. The advantage ``--embed`` is
simplicity. This module, on the other hand, can be used with multiple
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__
EXAMPLE
=======
In the ``Demos/freeze`` directory, there exist two Cython modules:
* ``lcmath.pyx``: A module that interfaces with the -lm library.
* ``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
factorial of the argument, while combinatorics prints n-choose-r.
The provided Makefile creates an executable, *nCr*, using combinatorics as the
"main" module. It basically performs the following (ignoring the compiler
flags)::
$ cython_freeze combinatorics lcmath > nCr.c
$ cython combinatorics.pyx
$ cython lcmath.pyx
$ gcc -c nCr.c
$ gcc -c combinatorics.c
$ gcc -c lcmath.c
$ gcc nCr.o combinatorics.o lcmath.o -o nCr
Because the combinatorics module was listed first, its ``__name__`` is set
to ``"__main__"``, while lcmath's is set to ``"lcmath"``. The executable now
contains a Python interpreter and both Cython modules. ::
$ ./nCr
USAGE: ./nCr n r
Prints n-choose-r.
$ ./nCr 15812351235 12
5.10028093999e+113
You may wish to build a normal Python interpreter, rather than having one
module as "main". This may happen if you want to use your module from an
interactive shell or from another script, yet you still want it statically
linked so you can profile it with gprof. To do this, add the ``--pymain``
flag to ``cython_freeze``. In the Makefile, the *python* executable is built
like this. ::
$ cython_freeze --pymain combinatorics lcmath -o python.c
$ gcc -c python.c
$ gcc python.o combinatorics.o lcmath.o -o python
Now ``python`` is a normal Python interpreter, but the lcmath and combinatorics
modules will be built into the executable. ::
$ ./python
Python 2.6.2 (release26-maint, Apr 19 2009, 01:58:18)
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import lcmath
>>> lcmath.factorial(155)
4.7891429014634364e+273
PREREQUISITES
=============
Cython 0.11.2 (or newer, assuming the API does not change)
SEE ALSO
========
* `Python <http://www.python.org>`_
* `Cython <http://www.cython.org>`_
* `freeze.py <http://wiki.python.org/moin/Freeze>`_
Demos/freeze/README.txt deleted 100644 → 0
+ 0
− 111
View file @ 807db222
NAME
====
cython_freeze - create a C file for embedding Cython modules
SYNOPSIS
========
cython_freeze [-o outfile] [-p] module [...]
DESCRIPTION
===========
**cython_freeze** generates a C source file to embed a Python interpreter
with one or more Cython modules built in. This allows one to create a single
executable from Cython code, without having to have separate shared objects
for each Cython module. A major advantage of this approach is that it allows
debugging with gprof(1), which does not work with shared objects.
Unless ``-p`` is given, the first module's ``__name__`` is set to
``"__main__"`` and is imported on startup; if ``-p`` is given, a normal Python
interpreter is built, with the given modules built into the binary.
Note that this method differs from ``cython --embed``. The ``--embed`` options
modifies the resulting C source file to include a ``main()`` function, so it
can only be used on a single Cython module. The advantage ``--embed`` is
simplicity. This module, on the other hand, can be used with multiple
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__
EXAMPLE
=======
In the Demos/freeze directory, there exist two Cython modules:
lcmath.pyx
A module that interfaces with the -lm library.
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
factorial of the argument, while combinatorics prints n-choose-r.
The provided Makefile creates an executable, *nCr*, using combinatorics as the
"main" module. It basically performs the following (ignoring the compiler
flags)::
$ cython_freeze combinatorics lcmath > nCr.c
$ cython combinatorics.pyx
$ cython lcmath.pyx
$ gcc -c nCr.c
$ gcc -c combinatorics.c
$ gcc -c lcmath.c
$ gcc nCr.o combinatorics.o lcmath.o -o nCr
Because the combinatorics module was listed first, its ``__name__`` is set
to ``"__main__"``, while lcmath's is set to ``"lcmath"``. The executable now
contains a Python interpreter and both Cython modules. ::
$ ./nCr
USAGE: ./nCr n r
Prints n-choose-r.
$ ./nCr 15812351235 12
5.10028093999e+113
You may wish to build a normal Python interpreter, rather than having one
module as "main". This may happen if you want to use your module from an
interactive shell or from another script, yet you still want it statically
linked so you can profile it with gprof. To do this, add the ``--pymain``
flag to ``cython_freeze``. In the Makefile, the *python* executable is built
like this. ::
$ cython_freeze --pymain combinatorics lcmath -o python.c
$ gcc -c python.c
$ gcc python.o combinatorics.o lcmath.o -o python
Now ``python`` is a normal Python interpreter, but the lcmath and combinatorics
modules will be built into the executable. ::
$ ./python
Python 2.6.2 (release26-maint, Apr 19 2009, 01:58:18)
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import lcmath
>>> lcmath.factorial(155)
4.7891429014634364e+273
PREREQUISITES
=============
Cython 0.11.2 (or newer, assuming the API does not change)
SEE ALSO
========
* `Python <http://www.python.org>`_
* `Cython <http://www.cython.org>`_
* `freeze.py <http://wiki.python.org/moin/Freeze>`_
bin/cython_freeze
+ 1
− 1
View file @ d02a3307
......@@ -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 deleted 100644 → 0
+ 0
− 73
View file @ 807db222
== 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
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:
import pyximport; pyximport.install()
import foo
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
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:
python -c "import foo"
See help(pyximport.install) to learn its options for controlling the
default behavior of "import" and "reload".
== 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
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
something more sophisticated like informing distutils of the
dependencies directly.
== Limitations ==
Pyximport does not give you any control over how your Pyrex 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
into a single library. Pyximport 1.2 will probably do this.
Pyximport does not hide the Distutils/GCC warnings and errors generated
by the import process. Arguably this will give you better feedback if
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 ==
"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
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
might do it but not necessarily: having it at the top level is VERY
HELPFUL for debugging Pyrex problems.
pyximport/README.rst 0 → 100644
+ 71
− 0
View file @ d02a3307
Pyximport
=========
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 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
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 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
Cython modules just with simple import statements. I like to test my
Cython modules like this::
python -c "import foo"
See help(pyximport.install) to learn its options for controlling the
default behavior of ``import`` and ``reload``.
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 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
something more sophisticated like informing distutils of the
dependencies directly.
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-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
by the import process. Arguably this will give you better feedback if
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
----------------------------------
``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
build directory as per normal for Distutils. If I could wave a magic
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 Cython problems.
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment