Hi Antoine,
I experienced the same behavior, and was able to trace down the cause with some digging into the Type169 source code. In my case, it seemed that specifying the name of the Python script alone, rather than the complete path, was causing an issue when the code attempts to strip the script name and script path into separate variables. The variable "scriptPath" contained just the name of the script, causing an undesired result when the Type169 code attempts to execute a "sys.path.append()" command through Python, resulting in the inability to Import the script.
I suspect that if you just specify the complete path to your script file in the entry box within the TRNSYS Type169 Special Cards configuration tab, rather than only the filename, the Type169 should work. (However, the fix I ended up using since I was already into the source code is described below just in case anyone finds it helpful.)
In my case, I fixed the issue in the source code by commenting out the existing line that executes the above mentioned command around line 267:
// PyRun_SimpleString(scriptPath.c_str());
Then I added the following two lines which (1) import the OS module in the Python session then (2) use that module to get the current working directory and append it to the path:
PyRun_SimpleString("import os");
PyRun_SimpleString("sys.path.append(os.getcwd())");
After making those changes and recompiling the Type169.dll, my issue was resolved when specifying just the name of a script within the current working directory. (Note, this makes it so that the script must ALWAYS be within the current working directory, as the path/filename stripping part of the code is now ignored.)
As for the TRNSYSpy module, it isn't a file, but is created within the Type169 program and appended to the Inittab just before python is initialized, which you'll see if you open the C++ source code around lines 262-264, so don't worry about that portion.
Best regards,
-Brandon