Re: [Python-ideas] Using Python for end user applications
On 7 February 2017 at 14:29, Steve Dower <steve.dower@python.org> wrote:
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.
My goal is explicitly self-contained applications - the "xcopy deployment" model. I'm looking for things that can be used in *very* constrained environments (no install ability, possibly not even any access to locations outside of My Documents).
I presume you mean http://electron.atom.io/? I've never used it, but again my goal is essentially command line apps here. Definitely "pure Python" apps. I don't know how I'd use electron from a Python script, but I'm guessing you're looking more at targeting GUI apps with traditional installers? It's an interesting area (GUI interfaces have always been a rough edge in Python development) but not one I am looking at at the moment. (Offtopic, but are there any tutorials on building apps using Python and Electron, as it sounds like an interesting thing to investigate). Paul
On Tue, Feb 7, 2017 at 3:27 PM, Paul Moore <p.f.moore@gmail.com> wrote:
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.
On 8 February 2017 at 00:49, eryk sun <eryksun@gmail.com> wrote:
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 :-)
That was my problem. I still have to support Windows 7. Thanks for the reminder.
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
On Tue, Feb 7, 2017 at 3:27 PM, Paul Moore <p.f.moore@gmail.com> wrote:
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.
On 8 February 2017 at 00:49, eryk sun <eryksun@gmail.com> wrote:
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 :-)
That was my problem. I still have to support Windows 7. Thanks for the reminder.
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
participants (2)
-
eryk sun -
Paul Moore