On Sep 17, 2009, at 20:03 , Stefan Behnel wrote: > > Magnus Lie Hetland wrote: >> Hmm. OK. I still don't understand why the missing __init__.py file >> means that the .pxd file is ignored... > > Because you instruct Cython to compile a file package/module.pyx and > it looks for a corresponding package/module.pxd.
Right. And that file is right there. > Since it cannot find the package, it can't find the .pxd file. I guess that's what I don't understand -- why would it need to find the package to do the compilation? If there's a .pxd file in the same directory as the .py(x) file, couldn't that be enough? (I understand that it currently isn't.) After all, no other requirements of the Python modules/packages are made, right? Cython doesn't check that various Python modules/packages can be imported, for example. Why check that the .pyx file is, in fact, in a real package? On Sep 17, 2009, at 20:11 , Dag Sverre Seljebotn wrote: > > Magnus Lie Hetland wrote: >> However, it would seem I >> can't compile the pure Python mode Cython files properly without >> adding an unused __init__.py file to the source directory? Or am I >> misunderstanding that part? > > Note that Python doesn't allow this either -- you can't spread a > Python > package across several directories. No, but I don't, really -- not after the Cython files have been compiled. The .so files are in the actual package hierarchy. I guess there's a part of the Cython semantics I'm not getting here -- i.e., why it cares about the surrounding Python infrastructure while compiling. On Sep 17, 2009, at 20:03 , Stefan Behnel wrote: > Magnus Lie Hetland wrote: >> At the moment, I'm trying to split my code into two separate dirs -- >> src/ and lib/ -- with src containing the Cython source (in pure >> Python >> mode .py files, along with .pxd files, as needed) and lib containing >> the Python code that is to be installed. > > Why do you do that? Because of a few practical problems (that I'd be happy to solve differently). 1. I'd like to automate the process of finding compilable files, so I don't have to manually update my setup.py file all the time. Previously, I globbed for .pyx files; now (because I'm forced to use .py files to get cython to compile pure Python mode correctly, it seems), I can't do that. So I need some way of discerning Cython source files from Python files. I thought I'd keep the Python files in the actual package hierarchy (where they belong), and the Cython source somewhere else, putting the .so files in the package hierarchy (where they, too, belong). 2. I'm just using standard mechanisms for installing, and Distutils will happily install the Cython source files (with .py endings) alongside the corresponding .so files. I don't really want this, although it doesn't hurt ... except it makes me a bit uneasy to think that there's a chance that the .py file will be imported instead of the .so file. Not sure if there's a clearly documented Python behavior here? 3. I'd like to be able to run tests and so forth in two ways -- one interpreting the Cython .py files (for coverage, among other things) and one using the .so files. Haven't thought through exactly how I'll implement this, but it seems it'll be easier to tell Python what to import if the (compiled) .py files and their .so files aren't in the same directory. > Just keep your source files in a correct package tree, regardless if > you compile them or not. You can make that a deployment detail. Well, that's what I used to do. And I'd be happy to keep doing it, if I can get the wrinkled mentioned above ironed out. I guess I could, e.g., explicitly list the compiled files, or grep for files importing cython, or something. And be more explicit about what should be installed (could generate that list based on the same info). Not sure how I'd handle the third issue, but I could kludge together something (e.g., "installing" two temporary versions for the tests, possibly using symlinks...). Suggestions for better solutions would be welcome. (At the moment, I'm keeping the Cython source in a fake packe, with a dummy __init__.py, to appease Cython, with a body that simply raises an exception, to avoid importing it by chance. I've dropped the --inplace for build_ext, and the .so files appear where they should.) > Stefan -- Magnus Lie Hetland http://hetland.org _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
