[Python-ideas] Using Python for end user applications

[eryk sun]

On Tue, Feb 7, 2017 at 3:27 PM, Paul Moore <p.f.moore at gmail.com> wrote:
> On 7 February 2017 at 14:29, Steve Dower <steve.dower at python.org> wrote:
>> You can leave python.exe out of your distribution to avoid it showing up on
>> PATH, or if your stub explicitly LoadLibrary's vcruntime140.dll and then
>> python36.dll you should be able to put them wherever you like.
>
> Understood, but I may need python.exe present if the script uses
> multiprocessing, so I'm trying to avoid doing that (while I'm doing
> things manually, I can do what I like, obviously, but a generic "build
> my app" tool has to be a bit more cautious).
>
> 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.

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.

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.