IronPython 2.7 -- CPython 3.x backwards compatibility...?

So, given that the way forward seems to be going to Python 3.x in the WIP/Rhino 8…

Just want to confirm some suppositions here:

  1. IronPython 2.7 will still be supported in V8 (according to what I have read here) so existing scripts that run in V7 should still run in V8 (assuming methods and/or commands haven’t changed).
  2. CPython 3.x scripts will not run in V7 or earlier

Assuming those suppositions are in fact valid (please correct me if they’re wrong), then I have the following questions:

  1. Am I right in assuming hat IronPython support will likely be phased out in some future version of Rhino (V9…)?
  2. Most importantly, is there a possibility to make a script that would be both forward compatible V8 → (i.e. written in CPython 3.x) and backwards compatible ← V7 (i.e. somehow switch to IronPython 2.7)?


I’m hoping the first number 1 is correct, and the answer to the second number 1 is no.

Adding a CPython component would be a great benefit to Grasshopper (likewise adding RhinoCPython to Rhino, but keeping RhinoPython)
Replacing a GhPython component with a CPython component could be a nightmare, even if there is a great bridge to allow CPython to call into .Net.

I’m assuming the Rhino and Grasshopper APIs will be compatible in any CPython and IronPython.

So what I did to write Python 2 code that was Python 3 ready, was try to write pure Python code, that:
a) doesn’t use any Python 2 syntax that was deprecated in Python 3 (e.g. print functions instead of print statements),
b) doesn’t use any Python 3 syntax not supported in Python 2 (e.g. type annotations, raise from, f-strings, and the Walrus), and
c) where there’s a free choice of Python 2 options, compatible code should use the Python 2 syntax that gives the Python 3 behaviour (e.g. class MyClass(object) to get ‘new style’ classes, that are just classes in Python 3).

However, to get things done with Rhino objects, eventually I needed a .Net System class (e.g. to define what a standard Colour was). It’s not impossible to create a CPython System .Net compatibility layer, but Iron Python / CPython compatibility is a far harder challenge than pure Python 2 / pure Python 3 compatibility.

It’s entirely possibly to have seemingly valid code, and still encounter devious and subtle differences in run-time behaviour between Iron and C Pythons, due to implementation details, e.g. the difference in when the garbage collector is precisely called (if the code base calls del on a file wrapper instead of just using a context manager - this wasn’t my code).

Another point is, CPython 3 users will want to use pip. Care should be taken to add the setting to pip, so it installs CPython only libraries in a dir that’s not in the IronPython sys.path

It’s already possible for plug-ins to break each other when two different Python versions share a directory on sys.path (and e.g. the user or their plug-in installs numpy to one).

If compatibility is possible, I would:
a): add a core/common directory low down on both sys.paths, for Rhino/ GH libraries that are compatible (and pure python libraries). This still allows each individual Python to import and override anything specific to itself that it needs beforehand, from its own dirs higher up sys.path

or b) Ship both Pythons’ core libraries compiled. CPython won’t import IronPython .dll files and likewise IronPython won’t import .pyc compiled modules. Does pip have a setting to prefer binary wheels over sdists where there’s a choice?