[Pyrex] ANN: Pyximport

Paul Prescod paul at prescod.net
Mon Jan 19 02:42:58 CET 2004


http://www.prescod.net/pyximport/

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 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"

Limitations
============

Pyximport 1.0 does not do dependency checking. So it cannot know that it 
should rebuild your Pyrex module because an include file changed. If one 
Pyrex file depends upon a second pyrex file through an import statement, 
  you are okay, because that will go through standard Python import 
processes. Simple dependency checking should not be rocket science as 
long as the dependencies are specified manually by the programmer 
(chasing dependencies through ".h" files would be too difficult and 
slow). Pyximport 1.1 will probably do it.

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 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.

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.

"setup.py install" does not modify sitecustomize.py for you. It seems 
there should be an easy way to do this...





More information about the Pyrex mailing list