Troubles with switching from IronPython2 to CPython3

Robot Structural Analysis
,
1

Hey everyone!

I wanted to switch from IronPython2 to CPython3, but I have some troubles.

I created a new support definition by writing a python script (see below).

import clr
from System import Environment
user = Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData)
sys.path.append(user +r'\Dynamo\Dynamo Revit\2.1\packages\Structural Analysis for Dynamo\bin')
clr.AddReference('interop.RobotOM')
from RobotOM import *
from System import Object

# Define input
SupportName = IN[0]
SupportData = IN[1]

application = RobotApplicationClass()
project = application.Project
structure = project.Structure
labels = structure.Labels
supports = []

for i in range(len(SupportName)):
        support = labels.Create(IRobotLabelType.I_LT_NODE_SUPPORT, SupportName[i])

        support.Data.UX = SupportData[i][0]
        support.Data.UY = SupportData[i][1]
        support.Data.UZ = SupportData[i][2]
        support.Data.RX = SupportData[i][3]
        support.Data.RY = SupportData[i][4]
        support.Data.RZ = SupportData[i][5]

        labels.Store(support)
        supports.append(support.Name)

# Assign the name to the OUT variable
OUT = supports

Here is the Dynamo Code:

Dynamo
Dynamo1919×1030 259 KB

It works perfectly with IronPython2, but it gives me the following warning with CPython3 and I have no idea why: AttributeError : ‘__ComObject’ object has no attribute ‘Data’

I would be grateful for any help!

Thanks in advance,
Ina

2

Hi, maybe you already found it, but this is a known limitation of the python.net package: it can’t handle COM API objects transparently.

This is something issued in the main Python3 discussion;

You can try to wrap the objects with the comobj class found here, but it’s a PITA to do it for every single COM object you encounter…

3

Hello @ina - As @sanzoghenzo mentions, there is not full parity between IronPython2 and CPython3. As such, you can still download the IronPython2.7 package from the package manager to keep using your existing workflow if you wish :slight_smile:

We suggest you update to CPython3 where possible as this is now the supported language, but in situations like this where there isn’t parity the suggestion is to use IronPython2 if you are comfortable with it no longer having security related patches as it has been discontinued now.

4

Probably worth noting this is a digup from 2016 originally so hopefully they found a solution across the 6 years in between (how do these threads even get resurfaced, weird).

I’ve been using the IronPython2.7 without any issues so far and plan to probably just keep using it as long as it works. Doesn’t seem to be a consensus from package authors on moving into CPython3 yet, very few seem to have as far as I can tell.

3 Likes
5

Hi, thanks a lot! It seems using CPython3 to handle COM API objects is definitely more difficult than with IronPython2. I will probably do it as @solamour suggested and keep IronPython2 where needed.

1 Like
6

Hi @solamour,
thanks a lot for your reply!
That’s exactly what I did. Seems to work pretty well :slight_smile:
It just feels wrong to use different python packages in the same Dynamo file, but I guess there is no issue with that?

7

No issues so long as everyone using the graph has that package :slight_smile: Technically, IronPython2 no longer receives patches, so no more security patches which means we cannot ship it ourselves, but can offer it in an “opt in” scenario like the Package Manager. CPython3 is fully up to date and security patched!

1 Like