pyscripter

See Passing a python object to a delphi function parameter - Python4Delphi - Delphi-PRAXiS [en] (delphipraxis.net)

No. You should try to understand the rules behind reference counting. (e.g. Reference Counting in Python (tripod.com)) Note that PyBytes_FromStringAndSize returns a new reference, so there is no need to increment the count. Adjust(Self) is needed when you need to access the Delphi object properties or methods.

On the Delphi side you can use PyArg_ParseTuple to get the pointer to the python object. Then you can either: use the python API to call the desired method on the python object or wrap the python object into a custom variant (VarPythonCreate in the VarPyth unit) and call the method in a high-level way. See tutorials and demos on VarPyth for details

Try the sources in pyscripter/python4delphi: Free components that wrap up Python into Delphi and Lazarus (FPC) (github.com) and follow the installation instructions. You should report the GetIt issue to the fork Embarcadero/python4delphi: Fork of P4D adding FireMonkey wrapper and Android support (github.com) which is used to create the GetIt package.

The IPC unit based on named pipes created by Russell Libby in 2003 and updated by @FPiette is worth checking. Blog article: Behind the connection: Inter Process Communication Using Pipes (francois-piette.blogspot.com) Source code: OverByte - Blog Source Code Named pipes in overlapped mode are super efficient and faster than sockets. See Synchronous and Overlapped Pipe I/O - Win32 apps | Microsoft Learn. See also I/O Completion Ports - Win32 apps | Microsoft Learn. I have contributed such a solution to the python library RPyC and it beats the socket based IPC by a large margin. The downside is that it is Windows only.

In case this of use to anyone: Quite often you find a bug in Delphi RTL and you come up with a fix. Patching involves replacing the RTL procedure with a new patched one. To do that you can use your favorite patching routine or library (I use Detours), but you need the address of the original function/method. a) Patching a non-virtual public method This is quite straight-forward: type TMethodType = procedure ... of object function GetAddress: Pointer; var MethodPtr : TMethodType; begin MethodPtr := TRTLClass(nil).PublicMethod; Result := TMethod(MethodPtr).Code; end; Note the type cast TRTLClass(nil). b) Patching a virtual public method If for example PublicMethod is virtual the above type cast TRTLClass(nil) with result in access violation, since to resolve the virtual method you need to access Self which is nil. You could create a class instance and use that instead of TRTLClass(nil), but apart from not being elegant, in some cases this has side-effects (for example it may require a valid windows handle). The trick is described in this Stackoverflow question. function GetAddress: Pointer; var VMT : NativeInt; MethodPtr: TMethodType; begin VMT := NativeInt(TRTLClass); MethodPtr := TRTLClass(@VMT).PublicMethod; Result := TMethod(MethodPtr).Code; end; This is based on two facts. A class is a pointer to the Virtual Method table (VMT) and an Object structure has as the first field a pointer to the VMT of its class. c) Patching a private virtual method The trick this time involves using a class helper to access the private method of the TRTLClass type TPrivateMethodType = procedure ... of object; TRTLClassHookFix = class helper for TRTLCLass function GetPriveMethodAddr: Pointer; end; function TRTLClassHookFix.GetPriveMethodAddr: Pointer; var VMT : NativeInt; MethodPtr: TPrivateMethodType; begin // Adjust Self to point to the VMT VMT := NativeInt(TRTLCLass); Self := TRTLCLass(@VMT); with Self do MethodPtr := PrivateMethod; Result := TMethod(MethodPtr).Code; end; That's it.

It should be 'ii:read_AP_register' if you are expecting two integer arguments.

Maybe this approach is useful.

See Embarcadero/PythonEnviroments: Components to simplify the deployment for Python environments for Delphi applications using Python4Delphi. (github.com)

Yes.

FWIW, I have tried the unofficial LSP patches and I could no longer debug programs. So I went back to the original dlls and debugging was available again.

What did you expect to get? Demo03 shows you how to use TPythonDelphiVar.

Use Demo 33 as a guide. As @David Heffernan said running python in threads is not trivial and unlikely to save you time.

FPyModule.Name := '__main__'; meeds to be FPyModule.ModuleName := '__main__'; Better to call your module something else (delphimodule or anything else. in the demos 'spam' is used) and import that module.

Please do. You will do everyone a favour.

Call you delphi module say "delphimodule" and in your script: import delphimodule print(delphimodule.QUANTITY); or from delphimodule import QUANTITY print(QUANTITY) Please look at the demos, before asking questions here and do yourself a favour. Do watch the two video tutorials. It is only two hours viewing and will save you masses of time if you plan to do any serious work with P4D.

Also do not call the module __main__. This is name is reserved for the main python module.

There is no need for that. It has already been initialized.

Create and link all non-visual components before you call LoadDLL.

Set PyEngine.IO before you call LoadDLL Redirection is setup by TPythonEngine.Initialize, which is called by LoadDLL.

You can use TPythonInputOutput event handlers to log python output to file or produce output in a console application.

In a 5 year old answer to a stackoverflow question @David Heffernan responded that "class properties cannot be accessed via RTTI". Is this still the case with recent versions of Delphi?

Watching the video tutorials I have pointed out and looking at the respective demos, would save you a lot of time.

python4delphi/Demos at master · pyscripter/python4delphi (github.com) python4delphi/Tutorials at master · pyscripter/python4delphi (github.com)

I was just writing code from memory without testing. What you did is fine.