pyscripter

This may be worth a look: neslib/Chet: C Header Translator for Delphi (github.com). From @Erik@Grijjy

WrapDelphi was designed to expose Delphi classes, records and interfaces to python. So it did not handle PPyObject parameters or return values. You could handle that by using the low-level approach (adding an Event to TPythonModule). However, I have now added to WrapDelphi support for exposing functions with parameters and/or results of type PPyObject. See WrapDelphiTest.pas in the latest version of the pyscripter/python4delphi: Free components that wrap up Python into Delphi and Lazarus (FPC) (github.com) repo. Example: Exposed Method: function TTestRttiAccess.PlaceInNewList(PyObj: PPyObject): PPyObject; begin with GetPythonEngine do begin Result := PyList_New(1); Py_XIncRef(PyObj); PyList_SetItem(Result, 0, PyObj); end; end; Usage in python from delphi import rtti_var list = rtti_var.PlaceInNewList('abc') The corresponding test in WrapDelphiTest: procedure TTestWrapDelphi.TestPPyObjects; var List: Variant; begin List := rtti_var.PlaceInNewList('abc'); Assert.IsTrue(VarIsPythonList(List)); Assert.AreEqual<string>(List.GetItem(0), 'abc'); end;

Does anybody know whether the workaround mentioned by @Uwe Raabe in Parnassus Bookmarks issue - again. - Delphi IDE and APIs - Delphi-PRAXiS [en] (delphipraxis.net) is still needed in Delphi 12.1?

Under Tools, Options, Language, Delphi, Library, I see a new platform in the drop-down list "Selected platform" called "Windows 64 bits (Modern)". This is in addition to "Windows 64 bits". There was no mention of it in today's seminar. Anyone knows what it is and how to use it?

PyEnum_Check and VarIsEnum have to do with enumerators and not the enum.Enum class. There are many ways to get the value. Using VarPyth: var a := VarPythonCreate(pColor); var val := a.value

Note that if you get the PyObject corresponding to the function by using for instance var PyMainModule: PPyObject; PyFunc: PPyObject; PyMainModule := GetPythonEngine.GetMainModule; PyFunc := GetPythonEngine.PyObject_GetAttrString (PyMainModule, PAnsiChar(AnsiString(method_name))); // When you finish with PyFunc you need to decrease the refcount You can then call the function in a number of different ways including the relatively high level: function EvalFunction(pyfunc:PPyObject; const args: array of const): Variant;

How about reading the documentation of PyObject_CallMethod or just googling for example usage?

@Remy Lebeau approach should work. (not tested) Alternatively you can use the more efficient: var PyMainModule: PPyObject; PyMainModule := GetPythonEngine.GetMainModule; GetPythonEngine.PyObject_CallMethod (PyMainModule, PAnsiChar(AnsiString(method_name)), nil);

It's not how it works.

As mentioned above you just use python strings in place of enumerated values, eg. exported delphi method using WrapDelphi procedure Test(Color: TColor) in python Test('RED')

I have no idea what you are trying to do, but it does not make sense to define the enumeration both in Delphi and in Python. I recommend that you familiarize yourself with: WrapDelphi - high level access to Delphi from python VarPyth - high level access to python from Delphi. The video tutorials offer a good introduction to both. If you use WrapDelphi to export delphi functions to python then you just use python strings in place of enumeration values.

result := ExtractPythonObjectFrom(Red);

There is no need to export anything. Delphi enum values are converted to python strings and sets to lists of strings. On the opposite direction you can access python enum values from Delphi in the same way you access other objects. The easiest way is to use VarPyth. var colorEnum := MainModule.Color var Red := colorEnum.RED

@Lainkes Under Project, Options, Version Info, you can choose to include version info with your project. The version info includes the version number but also a number of other strings including Comments. Your application can read those in a number of ways. See for instance How to determine Delphi Application Version - Stack Overflow, The most comprehensive way I found is using the Jcl library's unit JclFileInfo. This unit includes a class TJclFileVersionInfo which provides easy access to all information stored in version info. Here is for example a function that retrieves the version number using jcl: function ApplicationVersion : string; var ExeFile : string; begin ExeFile := Application.ExeName; if VersionResourceAvailable(ExeFile) then begin with TJclFileVersionInfo.Create(ExeFile) do begin Result := BinFileVersion; Free; end; end else Result := '1.0.0'; end; Note that this approach is Windows only. For Andoid apps you can access the version info differently (e,g,How can I get at the file version info of a file when running Delphi on Android? - Stack Overflow)

You need to decrease the refcount of these pyobjects after using them.

Hint: The answer is in PythonThreads · pyscripter/python4delphi Wiki (github.com) Other solutions include: Modify your scripts so that they do not create global variables (wrap everything inside a function which you execute) At the end of your python script delete (del) any global variables you create Use Run_CommandAsObjectWithDict or ExecStrings, passing new empty dictionaries to the optional locals, and globals parameters, which you then destroy.

Assuming you are on Windows use: import asyncio asyncio.set_event_loop_policy(asyncio.WindowsSelectorEventLoopPolicy()) loop = asyncio.new_event_loop() This should work both in the main thread and in other threads. Google for "set_wakeup_fd" to see this is a well known issue.

See PythonThreads · pyscripter/python4delphi Wiki (github.com) which explains how to run python code in delphi threads. This keeps the delphi main thread from blocking.

@iqrfYou are absolutely right, PyErr_Fetch returns new references and clears the error. The code in ProcessSystemExit has now been fixed. Thanks!

TColumn.SetVisible is called, so inside that method Self is the TColumn object on which the method is called.

The exit() function raises a SystemExit exception and if it is not handled it shuts down python. Don't use it in P4D scripts.

If you create an Engine client (e.g. TPythonDelphiVar TPythonModule) after the engine is initialized, you should call the client Initialize method. If the client is created before the engine is initialized, you should not call Initialize.

Could you post your minimal Delphi project in a zip file?

Destroying the engine and associated modules is normally instantaneous. Most of the demos do that. So that delay should be related to something "special" you are doing. Is python code running while you are doing that? As an aside, why do you need to manually free the engine?

You are not supposed to destroy TPythonModules before engine destruction. They are automatically destroyed when the engine is destroyed. And it does not achieve the desired effect of removing it from python. Python does not have a good mechanism for removing imported modules and this is not recommended in general. See for instance How do I really delete an imported module? (archive.org). Also from Reloading modules in Python - GeeksforGeeks Not sure what causes the delay.