In response to all of your responses:
No need to take offense, I was merely summarising the research you
posted in a way that looks more like scenarios or requirements. It's a
typical software engineering task. Being able to collect snippets and
let people draw their own conclusions is one thing, but those of us
(including yourself) who are actively working in this area are totally
allowed to present our analysis as well.
Given the raw material, the summary, and the recommendations, anyone
else can do the same analysis and join the discussion, and that's what
we're doing. But you can't simply present raw material and assume that
people will naturally end up at the same conclusion - that's how you end
up with overly simplistic plans where everyone "agrees" because they
projected their own opinions into it, then are surprised when it turns
out that other people had different opinions.
Cheers,
Steve
On 13May2019 1452, Victor Stinner wrote:
)Le lun. 13 mai 2019 à 18:28, Steve Dower <steve.do...@python.org> a écrit :
My take:
* all the examples are trying to be isolated from the system Python
install (except Vim?)
"Isolation" means different things:
* ignore configuration files
* ignore environment variables
* custom path configuration (sys.path, sys.executable, etc.)
It seems like the most common need is to have a custom path configuration.
Py_IsolatedFlag isn't used. Only py2app manually ignores a few
environment variables.
* all the examples want to import some of their own modules before
running user code
Well, running code between Py_Initialize() and running the final
Python code is not new, and my PEP doesn't change anything here: it's
still possible, as it was previously. You can use PyRun_SimpleFile()
after Py_Initialize() for example.
Maybe I misunderstood your point.
* nobody understands how to configure embedded Python :)
Well, that's the problem I'm trying to solve by designing an
homogeneous API, rather than scattered global configuration variables,
environment variables, function calls, etc.
Also from my own work with/on other projects:
* embedders need to integrate native thread management with Python threads
Sorry, I see the relationship with the initialization.
* embedders want to use their own files/libraries
That's the path configuration, no?
* embedders want to totally override getpath, not augment/configure it
On Python 3.7, Py_SetPath() is the closest thing to configure path
configuration. But I don't see how to override sys.executable
(Py_GetProgramFullPath), sys.prefix, sys.exec_prefix, nor (internal)
dll_path.
In the examples that I found, SetProgramName(), SetPythonHome() and
Py_SetPath() are called.
My PEP 587 allows to completely ignore getpath.c/getpath.c easily by
setting explicitly:
* use_module_search_path, module_search_paths
* executable
* prefix
* exec_prefix
* dll_path (Windows only)
If you set these fields, you fully control where Python looks for
modules. Extract of the C code:
/* Do we need to calculate the path? */
if (!config->use_module_search_paths
|| (config->executable == NULL)
|| (config->prefix == NULL)
#ifdef MS_WINDOWS
|| (config->dll_path == NULL)
#endif
|| (config->exec_prefix == NULL))
{
_PyInitError err = _PyCoreConfig_CalculatePathConfig(config);
if (_Py_INIT_FAILED(err)) {
return err;
}
}
OpenOffice doesn't bother with complex code, it just appends a path to
PYTHONPATH:
setenv("PYTHONPATH", getenv("PYTHONPATH") + ":" + path_bootstrap);
It can use PyWideStringList_Append(&config.module_search_paths,
path_bootstrap), as shown in one example of my PEP.
Victor
--
Night gathers, and now my watch begins. It shall not end until my death.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
