Different Python versions etc.

[MarkMLl]

Three related questions:

• Am I correct in assuming that the Lazarus Demo projects haven't yet been converted?

• Am I correct in noting that the library name has (at present) to be hardcoded in e.g. Python_Console/FormMain.pas?

• Am I correct from looking at the code that the Python version definitions in Definition.Inc are unused?

The last one is the result of my casually trying Python 2.7.

[Alexey-T]

3)

  PyNumberMethods = {$IFNDEF CPUX64}packed{$ENDIF} record

Some defintions are used. but most are not. It is legacy from Py4D.

[Alexey-T]

Lazarus Demo projects haven't yet been converted?

They are Laz projects, why they need to be converted.

[Alexey-T]

Am I correct in noting that the library name has (at present) to be hardcoded in e.g. Python_Console/FormMain.pas?

Yes, no autodetection. It's impossible on Linux

[MarkMLl]

  PyNumberMethods = {$IFNDEF CPUX64}packed{$ENDIF} record

Some defintions are used. but most are not. It is legacy from Py4D.

OK. So PYTHON27 etc. aren't used anywhere.

[MarkMLl]

Lazarus Demo projects haven't yet been converted?

They are Laz projects, why they need to be converted.

Demo01 etc. still refer to P4DLaz and don't compile.

[Alexey-T]

If you tell to @pyscripter to remove old defines, and he will do, I will sync my definitions.inc

[pyscripter]

I have removed all unused definitions.

[Alexey-T]

• sync'ed definitions.inc
• removed 4 DemoNN projects, was hard to adapt

[MarkMLl]

Am I correct in noting that the library name has (at present) to be hardcoded in e.g. Python_Console/FormMain.pas?

Yes, no autodetection. It's impossible on Linux

"Impossible" and "Linux" are words that are rarely heard together. At the very least and noting that on Debian the choices are

/usr/lib/x86_64-linux-gnu/libpython3.7m.so -> libpython3.7m.so.1 /usr/lib/x86_64-linux-gnu/libpython3.7m.so.1 -> libpython3.7m.so.1.0 /usr/lib/x86_64-linux-gnu/libpython3.7m.so.1.0

I think you'd make life easier if you used the less-specific libpython3.7m.so in preference to the fully-embellished libpython3.7m.so.1.0 at least until you had good reason.

In any event I notice that the original python4delphi project now claims FPC support, so I'm planning to check how they deal with things.

[Alexey-T]

Shortened path to remove '.1.0' in it

[MarkMLl]

But Python_Console already does this path define w/o folder path

const
  cPyLibraryWindows = 'python37.dll';
  cPyLibraryLinux = 'libpython3.8.so.1.0'; //default in Ubuntu 20.x
  cPyLibraryMac = '/Library/Frameworks/Python.framework/Versions/3.7/lib/libpython3.7.dylib';
  cPyZipWindows = 'python37.zip';

Full path was simply because it was ls output to illustrate that the various names were symlinked rather than being distinct files. This is of course exactly the issue which causes so much grief for people using databases etc.: Debian not actually creating the symlinks until a -dev package is installed...

[MarkMLl]

Shortened path to remove '.1.0' in it

I've just checked another system and you might want to consider (partially) reverting that (sorry, my fault). A system with limited development packages installed has

/usr/lib/x86_64-linux-gnu/libpython3.7m.so.1 -> libpython3.7m.so.1.0 /usr/lib/x86_64-linux-gnu/libpython3.7m.so.1.0

i.e. the .so (no digit suffix) might only be created when the Python development packages are installed at least on Debian.

[Alexey-T]

Reverted