A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2019-March/156945.html below:

[Python-Dev] PEP 578: Python Runtime Audit Hooks

[Python-Dev] PEP 578: Python Runtime Audit HooksSteve Dower steve.dower at python.org
Sat Mar 30 12:13:30 EDT 2019
On 30Mar.2019 0747, Nick Coghlan wrote:
> 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. 
> 
> 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.

It was called "open_for_exec" at one point, though I forget exactly why
we changed it. But I have no problem with moving it. Something like this?

PyImport_OpenForImport -> PyIO_OpenForExec
PyImport_SetOpenForImportHook -> PyIO_SetOpenForExecHook
importlib.util.open_for_import -> _io.open_for_exec

Or more in line with Nick's suggestion:

PyImport_OpenForImport -> PyIO_OpenExecutableCode
PyImport_SetOpenForImportHook -> PyIO_SetOpenExecutableCodeHook
importlib.util.open_for_import -> _io.open_executable_code

I dropped "For", but I don't really care that much about the name. I'd
be okay dropping either "executable" or "code" as well - I don't really
have a good sense of which will make people more likely to use this
correctly.

Cheers,
Steve
More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4