Hello @c.poupin. Thanks for reporting. Your observation is correct, there is a conceptual difference between engines that goes beyond Python syntax. We are currently working on reducing the exposure of those differences to users.
This case in particular worked for me in the latest daily build of Dynamo. Please give it a try and let us know if there is something we missed. Thanks again for reaching out!
Another element for the converter may be list.Add to list.append
It also seems to be pretty slow and spins for a few moments when trying to Load up the autocomplete suggestions for imports etc. Previously you could keep typing, but now it stops, spins, spins, waits, then gives you a list.
Hi @c.poupin. You posted quite a few things there, let me go one by one.
As you noticed, autocompletion for the CPython3 engine currently relies on the same mechanism used for the IronPython2 engine. Having an autocompletion engine specific for the new engine is currently on the works, but it didn’t make it to Dynamo 2.8.
Ref and Out
These two actually work with PythonNET but the way they do is not like in Iron Python and unexpected in my opinion. The ref/out parameters need to be provided but they are considered as inputs only. The output is actually obtained from the result of the function call, which is surprisingly a Python tuple. Here are a couple of examples showing this:
For this one I don’t have a better workaround than yours, so I will have to cheat
Here is an example using Dynamo’s own .NET classes to help interact with Excel. Unfortunately
some of these functions are not public, but the idea can be used with a custom library that is part of a package for instance. That helps overcome the limitations regarding COM interop in PythonNET.
Just wanted to add an alternative for COM interop. This can be achieved also using Python --> COM integration, without going through .NET. There is a module called pywin32 that serves this purpose. Here is an example equivalent to the one I showed before but using this pywin32 instead of relying on a custom .NET library.
Hi @ustncz. I tried and got the same error you did. I think it’s because we are running Python from .NET, so the threading mode is already initialized.
I was actually able to use the library if I commented out the offending line, where CoInitializeEx is called.
Nah - this is more of a ‘wait this didn’t work, is it the code or the implementation?’ thing which the community is here for.
For reference, any issues I have seen have warnings like now ‘library of that name found,’ and will throw the error early when you do your imports (assuming you do them together and early), but your mileage may vary.