Brett Cannon <br...@python.org> added the comment:
On Sat, Aug 4, 2018, 11:52 Jeroen Demeyer, <rep...@bugs.python.org> wrote: > > Jeroen Demeyer <j.deme...@ugent.be> added the comment: > > > 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. > > It's quite typical for packages to install stuff in site-packages which > the interpreter cannot load. In fact, that's the exactly the point of the > package_data argument to setup(), see > https://packaging.python.org/guides/distributing-packages-using-setuptools/#package-data > > Just as an example, Numpy installs tons of stuff inside > site-packages/numpy/ (header files, configuration files, data files for the > testsuite) > I think the key point no one is saying is that .pyc files are no longer on sys.path because they are in __pycache__ and those aren't importable unless you access them as namespace packages. So we have been moving to keeping artifacts like .pyc files off of sys.path. As Nick said, we have no generalized concept of source maps and I think coming up with that is what will be required to solve this as i personally don't view Loader.get_source() is not meant to be a generalized concept of some form of source code but Python source code. > ---------- > > _______________________________________ > Python tracker <rep...@bugs.python.org> > <https://bugs.python.org/issue32797> > _______________________________________ > ---------- _______________________________________ 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