The problem is not to bundle Python for your setup, you may just point out to end users, that they please install Python 2.7 or whichever version you need and specify the path of Python. The problem with a python installation required for your software is that other software having the same dependency already can cause conflicts. Not that their and your software run Python, that can be used in parallel, but like VFP has settings, PYthon has settings, you may require other settings than the other software. So I would only be working with a separate Python installation just for my software, and I don't see something like that without going through hoops like making my software a VM that runs completely separate from the host system in it's own little virtual universe, and I won't recommend to do that for somebody like A_Radiolog_inFoxPro.
Running Python within a webserver is having that separate universe, either under the roof of a website re runs as a support server for his software or in the intranet.
And as I already siad, if the software doesn't need distribtion, then you have the freedom to integrate whatever without thinking about such things as dependencies. because your only maintenance problems are with your own computers running your own software.
Maybe, A_Radiolog_inFoxPro, you even think this github repository is self contained and has everything in it to run Python with FoxPro, but you requira this Github package and a full Python installation. to run this. It may not be impossible to just pick out the essential pythonw.exe and some support DLLs to fully integrate, but as Python scripts depend on modules you'll have to also integrate subfolders lib, DLLs and then you're already near a full Python installation folder. Python like VFP knows its HOME() installation folder, so if a Windows system has two or mor Python installations it becomes hard to maintain what Home os for your Python integration, I think.
Looking into another software that uses Python for scripting within it - Gimp - that does not use a full Python installation it depnds on, it has some libpython2.7.dll and libpython3.9.dll in a bin subfolder of its application directory. It doesn't intefere with the Python installation I have, too. The goal opf the Python integration of Gimp is not to run general purpose Python code, but for scripting batch processing. It will not import anything I have available in my major dededicated Python installtion, it's not the intention to be able to, it's sufficient it can use modules of Gimp to have image processing features of gimp for automation batch processing purposes.
So, it's not impossible to integrate Python in software in a way that's not simply using a full Python installation. I'd be more impressed with a FoxPro Python installation that's using the same integratable libraries as Gimp does, though I also fully support that the idea of simply wrapping around a full Python installation makes it easier to integrate any general purpose Pyhton scripts that add to the import modules etc. as necessary. It's just something not as simply to redistribute, unless you make the assumption it will not collide with anything your end users have already installed.
Well, and the solution I still prpüpse in having a Web server integration with Python used centrally, that has one little disadvantage of the http request/response full turnaround time, that's surely a few ms everytime, but it's usable, otherwise no web services would be able to exist. With such a separate cloud based solution you have your own and only Python installation fully under control without needing to install anything at clients, you can choose the modules you need, configire PYthon as you want and upgrade whenever necessary. You can maintain your Pythong code and not necessarily need to build it into an EXE. Python is just like VFP not necessarily getting a boost from that, unless you use a build system that does not produce Python byte code but transpiles it to the C++ underlying the Python language and make a C++ binary from it that effectively becomes assmbler, just as fast assembler as you get from writing C++ code. CPyhton does that, I think, I never used that, Cython does similar things based on another idea, I'm not in the details. But such things will always not be fully compatible or need adjustments in the code. And, I think, A_Radiolog_inFoxPro. your main idea is to use solutions you find done in Python and not need to translate that to VFP code. It's surely a nice way to increase usable solutions. It's a huge effort, if all the Python code does is use web APIs you could also directly use from VFP, though. And many things like AI APis and other databases are directly integratable into VFP without going through Python.