Work in progress to improve Python 3 support

Introduction

This document lists issues we detected related to compatibility between Iron Python 2.7 and CPython 3.8 (via Python NET) engines. Next to each issue we provide a status of it:

• Fixed: The issue has been fixed. Either a release version is specified or it can be tested with our latest daily build.
• Planned: The issue is either being worked on or is planned for a future release.
• Not planned: The issue has been noted but has not been considered to be worked on.

We ask the community to provide feedback about these or other issues we might have overlooked.

Migrations from version 2 to 3 are purposely left out from this document, as they will be handled by a Migration Assistant which is currently in development. Documentation about it will be added later.

Issues

Python primitives are not .NET objects (Not planned)

Iron Python supports doing these kind of things:

x = 1
x.ToString()

That works because for Iron Python x is actually a variable in .NET, which happens to have a type that implements ToString as expected.

The previous does not work for native Python, because the Python type int does not have a ToString function. However, in Python you could achieve the same by doing this:

x = 1
str(x)

Certain types cannot be returned from a Python node (Planned 2.8)

An easy repro of the issue would be to use the following code in a Python node, with the CPython3 engine:

s = { 'hello', 'world' }
OUT = s

The previous tried to return a Python set from a Python node. That type is not currently supported, and will also lead to a crash due to a bug. Support for Python types is being improved and the crash bug will be fixed soon.

TypeError : No method matches given arguments (WIP and Planned 2.8)

This is an error that might be seen from a .NET function call that receives Python types as arguments. One example that reproduced this in Dynamo 2.7 is:

import clr
clr.AddReference('ProtoGeometry')
from Autodesk.DesignScript.Geometry import *

point = Point.ByCoordinates(0,0,0)

In this case, the issue was caused by an inability of Python.NET to determine the overload of Point.ByCoordinates to be called, when it should have been Point.ByCoordinates(double x, double y, double z). Event though the arguments of type Python int with values of 0 could be converted to Python float with values of 0.0, Python.NET did not attempt this and failed with the message in the title.

This specific problem for int to float conversions was fixed and will be released in 2.8. Unfortunately the message is quite generic and might describe other failed conversions or scenarios where the method was not found due to being misspelled, for instance. If you run into this, please reach out to us with a detailed repro of the issue.

No line number on Python errors (Fixed)

Most often than not, the CPython3 engine would omit the line number where an error occurred, making it harder to debug long Python scripts. Errors of type TypeError would never provide a line number, while others of type SyntaxError would.

This was a rather inconvenient omission in Python.NET that was fixed but not yet released.

Python with blocks don't call Dispose for wrapped IDisposable .NET objects (Not planned)

The following example shows what this issue is about:

with ClassThatImplementsIDisposable() as something:
  pass

Iron Python would call Dispose() automatically for something when exiting the with block. This is not the case for Python.NET, so developers should be aware and call Dispose() explicitly if required.

Very big integers are not supported (Fixed)

Python supports through its int type integer values of any size. However, taking that value from Python to .NET requires special considerations, because the target type needs to be able to support very large values as well. Iron Python convert to BigInteger automatically, so the following code example would work:

# That is bigger than what would fit in an Int64
x = 11111111111111111111
OUT = x

Python.NET did not support converting large integers to BigInteger out of the box, so additional work was required to make it work.

Custom Python objects cannot transcend a Python script node (Not planned)

Iron Python allowed to return objects of custom classes defined in the same Python script node. An example of this would be the following:

class Dog:
  kind = 'canine'
  
  def __init__(self, name):
    self.name = name

OUT = Dog('Rex')

Even though the output from that node would not be of much use in Dynamo, it could be reused in another Python node, allowing certain degree of code reuse between nodes.

The type of integration that Python.NET provides does not allow to move custom objects out of the scope of a Python node.