Python Engines (Poll)

Hello all

With Revit(2022) or Civil3D(2022), It is now possible to use 2 Python engines in Dynamo

  • IronPython2 (target Python 2.7)
  • CPython3 with Pythonnet Bridge (target Python 3.7+)

From Dynamo 2.7 onwards, you now have the option of using either IronPython2 (Which has historically been in Dynamo) or the new CPython3 - available as different engines on each Python node which compute using either Python 2 or Python 3 code respectively. Note - you can use both versions in a single graph.

From Dynamo 2.11 onwards, CPython3 will be the both the default engine and officially supported Python engine inside of Dynamo. You will be able to access IronPython2 via the Package Manager on a per-user basis.

Beyond the difference between Python 2 and Python 3, there are some differences with the .NET 4.0+ Common Language Runtime (CLR) integration:

  • IronPython2 → IronPython (more detail here)
    IronPython is a .NET native Implementation of Python for .NET Framework that is built on top of the Dynamic Language Runtime.
  • CPython3 → Python.NET (more detail here)
    Python for .NET is a package that gives Python programmers nearly seamless integration with the .NET Common Language Runtime (CLR)
What are you planning? (eventually)
  • I plan to migrate completely to CPython3/Pythonnet
  • I plan to stay on IronPython
  • I plan to use the 2 engines (mainly IronPython)
  • I plan to use the 2 engines (mainly CPython3/Pythonnet)

0 voters

Note
one should not see IronPython and CPython/PythonNet as competitors, each have different qualities

7 Likes

In my opinion the advantages of CPython3 is enough that staying with the old is foolhardy after a point. Moving past Python 2 should eventually be a goal for everyone - locking a larger package (say Genius Loci, or Clockwork) down to 2 at the next release and starting to develop only on 3 makes sense to me.

6 Likes

I dont see them as competitors, i see one as a security risk because of the lack of support for Python 2 anymore. Python 2 had its EOL on 1st Jan 2020, and IronPython is developed by volunteers

Therefore we need to move onto the latest version to hopefully stay away from security risks if any end up being found.

Note: IronPython3 has been in development for a long time, still in WIP status and is done by volunteers only.

2 Likes

They both have benefits and many costs, PythonNet is also a non sponsored project AFAIK.

3 Likes

for info IronPython3 is coming very soon in version 3.4

2 Likes

These “Software makers” or volunteers are just like Dynamo graph makers i think, “ok guys” :triumph: :triumph:

2 Likes

If we are only talking about Python 2 vs Python 3, the choice does not really arise (Python3).

Now if we compare the .Net integration, IronPython has some advantages over the PythonNet package, which can make the choice a little more complicated for some depending on their level of experience.

An example with an indexed property

Edit
After thinking about it (no pun intended) there is finally easier for this example…

3 Likes

Surely everything NEW is going to be made with CPython 3.

My only concern would be the given time to us, package developers, to migrate all of our EXISTED nodes to CPython3…

For example my package consists of almost 700 custom nodes, and more than 500 dyn graphs, many which uses Ironpython 2.
We would eventually move to CPython3, but it will take years… 4 or 5 at least in my side, as I will progressively migrate/test nodes in each update, and it’s really hard work.

5 Likes

You just made me a little nervous with your initial CPython3 example :joy:

1 Like