This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author paul.moore
Recipients brett.cannon, eric.snow, erik.bray, jdemeyer, ncoghlan, paul.moore, petr.viktorin, sth
Date 2018-08-04.18:25:00
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1533407100.28.0.56676864532.issue32797@psf.upfronthosting.co.za>
In-reply-to
Content
> What's wrong with that? Installing the .pyx sources together with the .so compiled modules makes a lot of sense to me: it is very analogous to installing the .py sources together with the .pyc byte-compiled files. In https://bugs.python.org/issue32797#msg315965 Paul Moore disagreed with that analogy, but I don't quite understand why.

Because if someone deletes the .pyc file, the interpreter can (and will) regenerate it using the .py file. If someone deletes the .so file, you're stuck. Having the .pyx file present won't help you.

In my view (and that of the documentation for sys.path), sys.path is where you put things that the Python interpreter can load - .so files, .pyc files and .py files.

Looking for source to report as part of a traceback is a separate process, and there's no immediate reason why it should involve sys.path. The fact that historically it did (because that worked for pure Python modules that shipped with source) doesn't mean it's the right solution. I'd rather see a well-designed protocol for "find me the source for this module" that tools like Cython can support, than trying to patch up the loader protocol and sys.path to do something they weren't ever designed for.
History
Date User Action Args
2018-08-04 18:25:00paul.mooresetrecipients: + paul.moore, brett.cannon, ncoghlan, petr.viktorin, erik.bray, eric.snow, sth, jdemeyer
2018-08-04 18:25:00paul.mooresetmessageid: <1533407100.28.0.56676864532.issue32797@psf.upfronthosting.co.za>
2018-08-04 18:25:00paul.moorelinkissue32797 messages
2018-08-04 18:25:00paul.moorecreate