On Sat, 30 Mar 2019 at 06:14, Steve Dower email@example.com wrote:
On 29Mar2019 1218, Christian Heimes wrote:
On 28/03/2019 23.35, Steve Dower wrote:
There is no Python API provided for changing the open hook. To modify import behavior from Python code, use the existing functionality provided by ``importlib``.
I think that the import hook needs to be extended. It only works for simple Python files or pyc files. There are at least two other important scenarios: zipimport and shared libraries.
For example how does the importhook work in regarding of alternative importers like zipimport? What does the import hook 'see' for an import from a zipfile?
Yes, good point. I think opening the zip file with open_for_import() is the right place to do it, as this operation relates to opening the file on disk rather than files within it.
I like this PEP in principle, but the specific "open_for_import" name bothers me a lot, as it implies that "importing" is the only situation where a file will be opened for code execution. Accordingly, I think proceeding with that name will increase the risk of unintentional audit bypasses, as folks (both within the core development team and outside it) use the regular open function for data that they then pass to exec(), or for some other purpose that nevertheless allows arbitrary code execution (e.g. the shelve module loading pickle files from disk).
If this part of the API were lower down the stack (e.g. "_io.open_for_code_execution") then I think it would make more sense - APIs like tokenize.open(), runpy.run_path(), PyRun_SimpleFile(), shelve, etc, could use that, without having to introduce a dependency on importlib to get access to the functionality.