Kill to CPython3

Developers
,
1

Both the Dynamo API and the Revit API use .NET resources. I’m trying hard to understand why use a Python engine that doesn’t “see” .NET types.

A lot of my code in IronPython2 uses Linq (which was wonderful), but CPython3 broke them all.

Even more, some Dynamo libs are not working, such as some list nodes like List.GroupByKey()

Trying to use this method (node) in CPython3 just doesn’t work.

# by onBIM Technology
# www.onbim.net
# file name: xxxx.py

# REFERENCES AND IMPORTS
# BEGIN>>>>>

import clr

# <<< Iron Python Modules >>>
# BEGIN

# Import traceback module from Iron Python
import traceback

# END

# Import Dynamo Library Nodes - Core
clr.AddReference('DSCoreNodes')
from DSCore import List as DynamoList

# REFERENCES AND IMPORTS
# END<<<<<

# FUNCTIONS
# BEGIN>>>>>

def ToList(item):
    """
    Turns a item into list
    """
    return item if isinstance(item, list) else [item]

# FUNCTIONS
# END<<<<<

# INPUTS AND VARIABLES DECLARATIONS
# BEGIN>>>>>

results = ToList(IN[0])

result = []

# INPUTS AND VARIABLES DECLARATIONS
# END<<<<<

# MAIN CODE
# BEGIN>>>>>

try:
    errorReport = None

    placedRmstd = results[2]

    rmstdGroupedByKeys =\
        DynamoList\
        .GroupByKey(
            placedRmstd,
            [rmstd.Name for rmstd in placedRmstd]
        )

    placedAmounts = [
        len(group)
        for group in rmstdGroupedByKeys["groups"]
    ]

    rectangles = [
        rmstd.Rectangle
        for rmstd in placedRmstd
    ]
    
    colorizedSurfaces = [
        rmstd.GetColorizedSurface()
        for rmstd in placedRmstd
    ]

    totalPlacedRooms = len(placedRmstd)

    result = [
        rmstdGroupedByKeys["groups"],
        placedAmounts,
        totalPlacedRooms,
        rectangles,
        colorizedSurfaces,
    ]

except Exception as e:
    # if error occurs anywhere in the process catch it
    errorReport = traceback.format_exc()

#Assign your output to the OUT variable
if errorReport == None:
    OUT = result
else:
    OUT = errorReport

# MAIN CODE
# END<<<<<

This works fine on IronPython2 like showed in image below

image
image1122×832 123 KB

Now look at the same code executed on CPython3

image
image1217×538 113 KB

I needed to remove just this here for it to work

    rmstdGroupedByKeys =\
        DynamoList\
        .GroupByKey(
            placedRmstd,
            [rmstd.Name for rmstd in placedRmstd]
        )

Having a compatibility issue with some Python functions is even understandable, but not having compatibility with .NET and even Dynamo’s own libs honestly makes CPython3 unviable to be used for things that are even a little more complex. Besides being much slower than IronPython 2.

It would help a lot if this was fixed.

1 Like
2

Adsk decided IronPython was at the end of its life. They were probably a bit premature.
And I’m sure this all ties in with Adsk becoming an API platform rather than a software company.

I’ve just ditched dynamo for 90% of my stuff and use pyRevit as the font end. I can choose IronPython or CPython. But am slowly getting everything over to CPython. Plus, pyRevit supports .cs and .vb scripts. Very flexible. And If I need any heavy lifting, I’ll just jump over to .Net .cs scripts.

I expect they will have this hammed out by the next release of Revit that is right around the corner.

2 Likes
3

I suffered a lot at first, but I migrated to C#, making ZeroTouch nodes or Revit plugins. It’s an abyss of performance improvement, code reliability and maintainability. However, I still have a lot of things in Python and sometimes a client asks me for something specifically in Python. It’s been a pain with this new CPython.

3 Likes
4

I’ve hit quite a few brick walls with CP3 as well, which for me lead me to other platforms. I wont elaborate on this as it has bothered some users in the past.

From reading threads, there seems to be some issues with how some classes and inheritance? is managed (can’t 100% remember if that was the right term, but might be…). Some things seem to require completely different approaches, whilst a few scenarios I’ve searched for on the forums lead to a ‘we don’t have a solution for this currently’ type answer.

A few users have pointed out that IronPython3 is now available and doesn’t feature the core reason Autodesk uses for ditching IP2 (security). Hoping to see it return in future, but personally not hopeful as all responses usually point to choosing CP3 as the future approach.

1 Like
5

CP3 does not like WPF form :frowning: I don’t want to rewrite everything. I wish there will be builtin Ironpython 3.4 for dynamo in the future

2 Likes
6

Because it doesn’t work with .NET Framework, even though Dynamo and Revit APIs are .NET.

For the same reason, Dynamo nodes that uses .NET doesn’t work too, wich is my case showed here. Which is completly non sense.

7

Dont forget IronPython 2 was built on Python2 which become end of life in January 2020 and therefore generally anything Python2 becomes a Vulnerability as it wont receive any updates.

I know of a couple of vulnerabilities in python that have been fixed in Python3 but will not arrive in Python2. This is one: CVE - CVE-2022-0391

Yes it is a pain but would your IT team(or Cyber Security Compliance) allow End of Life Software if they knew?

To add to the mix I have seen that even Grasshopper is adding Cpython3, it is in Rhino8 WIP build.

2 Likes
8

We have been looking to update to the newer releases of PythonNet which will hopefully deal with a bunch of issues that have been reported - we will need to fold our own fixes in though for specific Dynamo interop.

In addition I think we have built the necessary infrastructure to load dynamic python engines, so IronPython 3 should be able to be loaded as a package…

8 Likes
9

If IT had things their way, firms would not even use computers these days with the amount of exploits and vulnerabilities on them. Revit addins have literally provided backdoors into some of the biggest firms out there, ith the weakpoint being the user, but the method being a maliciously built addin.

The counterpoint to vulnerabilities is to manage the development of tools carefully and mitigate said risks along the way via training and limited access to source code authoring - to discard a functional toolkit with a partially flawed one is a ‘bandaid without much stick’ approach for most.

I can’t see Dynamo userbase generally embracing CP3 on average, but it will encourage people towards zero touch and addin deevelopment at least as a silver lining. That or tools/packages where they have an inbuilt option to proceed at risk with IP2, of course by their own choice and need to manage said risk.

I think the Autodesk team has given a great deal of ways to work around this such as using the IP2 package, the migration assistant and also just helping on the forums, so it’s really just the things CP3 can’t do in a similar manner if not at all that give frustration to the users who have genuinely tried to work with CP3 versus just wanting to hold onto IP2. If there’s intent to further explore these issues in future as hinted in the replies that’s great!

2 Likes