[Python-ideas] Using Python for end user applications

[Paul Moore]

On 8 February 2017 at 00:49, eryk sun <eryksun at gmail.com> wrote:
>> LoadLibrary might work (I'm only calling Py_Main). I seem to recall
>> trying this before and having issues but that might have been an
>> earlier iteration which made more complex use of the C API. Also, I
>> want to load python3.dll (the stable ABI) as I don't want to have to
>> rebuild the stub once for each Python version, or have to search for
>> the correct DLL in C. But I'll definitely give that a go.
>
> LoadLibrary and GetProcAddress will work, but that would get tedious
> if a program needed a lot of Python's API. It's also a bit of a kludge
> having to manually call LoadLibrary with a given DLL order.

Tell me about it :-) That's what the Vim Python interface does (not so
much to load when not on PATH, as to degrade gracefully when Python
isn't installed), and it's stunningly painful to set up :-)

> For the latter, I wish we could simply load python3.dll using
> LoadLibraryEx with LOAD_WITH_ALTERED_SEARCH_PATH, but it doesn't work
> in good old Windows 7. python3.dll doesn't depend on python3x.dll in
> its DLL import table. I discovered in issue 29399 that in this case
> the loader in Windows 7 doesn't use the altered search path of
> python3.dll to load python3x.dll and vcruntime140.dll.

That was my problem. I still have to support Windows 7. Thanks for the reminder.

> As you're currently doing (as we discussed last September), creating
> an assembly in a subdirectory works in all supported Windows versions,
> and it's the most convenient way to access all of Python's limited
> API.

Yes, it's a really good method, although it doesn't work 100% for
Python 3.5, as the "pyvenv.cfg" approach for isolating the Python
environment has a glitch. Offhand I can't recall the details (and as
it's fixed with the new approach in 3.6, it's not really relevant any
more) but IIRC I was getting some issues with 3.5. Hence why my
solution is likely to be 3.6+ only.

Paul