On 30Mar2019 0913, Steve Dower wrote: > 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. Looking at what we already have, perhaps putting it under "PyFile_OpenForExecute" would make the most sense? We don't currently have any public "PyIO" types or functions. Bikeshedding now, but as I'm the only one really participating in it, I think it's allowed :) Cheers, Steve
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