SetProgramArgs() should not be called if you are creating an extension

[pyscripter]

Discussed in https://github.com/pyscripter/python4delphi/discussions/430

^{Originally posted by **LennertP** August 2, 2023} Hi! Recently I noticed that sys.argv is modified when extending Python using PythonEngine.pas. I found that this is because SetProgramArgs() inserts an empty string in the call to PySys_SetArgv(). My understanding is that calling PySys_SetArgv() is useful when embedding Python, but when extending Python by using PythonEngine.pas to create a .pyd this seems undesirable. I created this small pargs.py file to reproduce the issue: import sys print(sys.argv) Initially the output running 'python pargs.py' is: ['pargs.py'] When I also import my own package implemented using PythonEngine.pas like this: import mypackage import sys print(sys.argv) running 'python pargs.py' again now results in; ['', 'pargs.py'] Do you think it is a good idea to skip calling the SetProgramArgs procedure when extending Python? If yes, how can we discriminate between extending Python and embedding Python in TPythonEngine.Initialize? Best regards and many thanks for maintaining this excellent PythonEngine, Lennert.

[pyscripter]

@lmbelo Any thoughts?

[pyscripter]

@LennertP
You are most likely not using LoadDllInExtensionModule to load the python dll in your Delphi created python module. See https://github.com/pyscripter/python4delphi/blob/master/Modules/DemoModule/uMain.pas

[lmbelo]

He is certainly not using LoadDllInExtensionModule.

[LennertP]

The version of PythonEngine.pas that I was using didn't have this LoadDllInExtensionModule procedure (I didn't find a version number, but downloaded October 2020) . If I understand correctly this will set the FInExtensionModule boolean which will subsequently skip a.o. the call to SetProgramArgs. So, I guess upgrading to the latest version combined with calling LoadDllInExtensionModule should resolve this issue, right?

[pyscripter]

So, I guess upgrading to the latest version combined with calling LoadDllInExtensionModule should resolve this issue, right?

Indeed.