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.dower at 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.
>
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