Python Death Clock

There is just over a year to go on the Python 2.7 death clock :clock11:

Have Mcneel plans moved on at all in terms of Python 3 support? Two major features of Python are the large standard library and the large number of available technical and scientific libraries.
This has really accelerated over the last 2 years with some great tools in recent versions of Python 3 so supporting Python 3 would give Rhino developers access to some amazing machine learning, data visualisation and other tools. There are also lots of tools and support for switching code from 2 to 3.
I see the 3dm project is py3 compatible but is that a moonshot? is there an official strategy for Python 3 support in Rhino and Grasshopper?
By the way : thank you very much for integrating Python in Rhino! This makes my working life much less repetitive and tedious and I feel like I am just starting to explore the possibilities :slight_smile:
I know that Rhino currently uses IronPython, and I see that that project picked up life again earlier in 2018 after a long hiatus. I am also aware of the Python .Net project which supports Python 3 but don’t know if that is suitable for Rhino integration…?

You forget that Rhino’s Python is IronPython. Don’t think there is a V3 for that yet…

No plans that I am aware of. And anyway, Python 2.7 lives for as long as it is being used (:

There is https://github.com/IronLanguages/ironpython3 but I don’t know when it will be production-ready.

1 Like

Yes I am aware - I modified my post to reflect this

I wanted that py3 compatibility for Blender 2.8, as I wanted to start import_3dm as a new Blender add-on. the rhino3dm more-or-less lives outside Rhino itself, so no direct influence from the py3 compatibility from that to the main Rhino project.

I will have to try rhino3dm outside Rhino - I sometimes need Pandas dataframes and I am targetting a Rhino → Matlab → Paraview toolchain. I’m a bit nervous about the newness of it all - I don’t want to have to rewrite everything if the API changes.

I don’t forsee large, architectural, changes in the rhino3dm API, especially considering that the Rhino file format is quite “flat”. I think @stevebaer probably will agree with that.

Now the compute/inside APIs I don’t know how stable they are, but I think you should be able to get quite far with already ‘just’ the file format module.

Nathan’s right; I doubt we’ll make a whole lot of changes as this is simply writing OpenNURBS bindings in python and I am following the patterns that we have used in RhinoCommon. I’m not one to go dramatically changing things just for change’s sake.

OK thanks both - I shall get stuck in next time I’m linking data to geometry. I’m still not sure how best to fit all the pieces together but this could be the missing element…

Ahh yes, about that - the latest python developers survey is out :smiley:

Sorry @nathanletwory I’m revoking your solution :open_mouth: given @stevebaer’s exciting announcement this morning :slight_smile: :snake:

That is fine - I’ll be typing my surface tools using this as well . Rhino Inside used in Blender.

1 Like

Latest update on Ironpython 3 development from those who are working (unpaid, open source) on it: ”I wouldn’t say it’s ready for any kind of release, but it works for a lot of scenarios”

So if people are feeling brave then I guess they could download, (compile?) and install it outside of Rhino.

1 Like

Some interesting updates from the Dynamo team:

Looks like they’re implementing Python.NET, which I’m sure comes with its own can of worms (and is another potentially brittle dependency ala the dead Enthought stuff). But it’s cool to see them attempt to provide official CPython 3 support out of the box.

1 Like

and now CPython 3 in Rhino 8

3 Likes

OK, time to get rhino 8 WIP

3 Likes

RIP in pepperoni linguinis IronPython…

F

1 Like