Stefan Behnel <stefan...@behnel.de> added the comment:
FWIW, I can see that Cython is a special case because it can control the source line mapping and reporting through the C-API. Other code generators might not be able to do that, e.g. for a DSL or template language that gets translated to Python code, for which an explicit source mapping would be required. But, I definitely see the analogy between .py files and .pyx files. In fact, .pyx files often originate from renaming .py files. And keep in mind that Cython can also compile .py files, which leads to .so files in the same package directory. Installing the .pyx files alongside with the .so files is currently easy for our users because distutils does it automatically. Changing the place where they get installed would require tooling support and most likely also changes on user side in all Cython projects out there (unless it's configured through the distutils Extension object, which Cython can control). The recommended way to structure Cython packages is to have the .pyx files where the resulting extension modules go, in their package, so that both end up next to each other with "setup.py build_ext --inplace", but also to make relative imports and inclusions work through the normal path lookup mechanism in Cython. Keeping two identical package structures in different places, one for .py files and generated .so files, and one for Cython source files (.pyx, .pxd, .pxi), is not desirable from a user perspective, and would require namespace packages for the lookup, where otherwise a simple single Python package structure would suffice. That would complicate Cython's internal compile time import lookup system quite a bit. If we keep that single package structure (and from a user's perspective, I'm all for it), but change the way source files are looked up, we would have to additionally come up with a way to support the debugging case in a source checkout, where .pyx files and .so file are necessarily in the same package directory, together with the .py files. This whole idea looks backwards and complicated. As Brett noted, .pyc files were moved out of the source tree, because they are build time artifacts and not sources. With that analogy, it's the .so files that would have to move, not the .pyx or .py source files, which are sources for the compiled .so files. ---------- nosy: +scoder _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32797> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
