Hi,
Rhino 3.9 is the last version that is not supported no more.
@eirannejad would it be possible to increate the version from 3.9.10 to 3.10 ?
3 Likes
On my list
RH-81753 Upgrade Python Runtime
When do you think you would have time for this upgrade?
Itâs not gonna go into Rhino 8. Would you be able to test it out Rhino 9 WIP?
1 Like
Yes, would it be possible to do this in the next Rhino9 WIP release?
Why do you need this to be updated?
Probably not that quick. But will implement this as soon as possible. There is a bunch of things I need to do before swapping python versions
Reasons:
- None of the libraries for compas will be built for 3.9, as it is considered non-supported version.
- Typing is of the things that changed a lot in 3.10 and is much more better than in previous versions.
- All the C++ binding, nanobind, scikit-build libraries from github actions and documentations gives constant warnings to update to 3.11 version.
So it is not personal preference. For python you normally want to be at least in the last security maintained version which is now 3.11, one before the newer version to be bug free.
2 Likes
My 5 cent hereâŚ
Frankly speaking, I think having a native Python editor and an enclosed python inside Rhino is not a very good decision made.
Due to Rhinoâs release cycle, and the limited support from McNeel, an up-to-date version of Python inside Rhino is almost impossible. And you always have dependency issues that very limited people have encountered (Consider the developer of python on Rhino platform).
The v3.9 may be due to the fact that they started testing it during Rhino 8 WIP several years ago, made it stable enough to be integrated in to Rhino, and then Rhino 8 is released.
(This probably will happen again: v3.11 for Rhino 9 WIP, then when it is released, Python will abandon it and make v3.14 the minimum support version)
To me, the best shot would be sth similar to Hop in Grasshopper, that McNeel just release a Python library contains the geometry classes from Rhino, like OpenNURBS, to the python community.
Whether it is open-sourced or not, doesnât matter.
The key is to integrate Rhinoâs geometry into pythonâs community, not the reverse.
Then you can attract more users, better community support, and a much smoother development experience in any editor (VsCode, Vim, whatever), and then use Rhino as an end Visualizer.
This is what I see the most attractive approach of combining Rhino and Python.
Otherwise, this kind of post will appear again and again, and the problem will be never resolved unless McNeel invest enough effort to support an internal Python team.
And lastly, modern editor with LSP support is already a software engineering monster. Donât think of develop something on the same level without a large team. Not to say additional plugin support and eco-system â The native editor is really not attractive to useâŚ
2 Likes
I think is a way to get Rhino running inside Python. Here you can call RhinoCommon from within Python: Rhino Inside Python Project
Check the latest release date and supported Python versionâŚ
Clearly it is abandoned if not nearlyâŚ
But that is the technology direction you would be able to use? Not sure how hard it is to update to the new versions of Python.
I just ran this in Python 3.13. Works so far:
import rhinoinside
rhinoinside.load()
import System
import Rhino
# for now, you need to explicitly use floating point
# numbers in Point3d constructor
pts = System.Collections.Generic.List[Rhino.Geometry.Point3d]()
pts.Add(Rhino.Geometry.Point3d(0.0,0.0,0.0))
pts.Add(Rhino.Geometry.Point3d(1.0,0.0,0.0))
pts.Add(Rhino.Geometry.Point3d(1.5,2.0,0.0))
crv = Rhino.Geometry.Curve.CreateInterpolatedCurve(pts,3)
print (crv.GetLength())
2 Likes
You raise good and valid points here. I particularly like the integrate Rhinoâs geometry into pythonâs community part. I like to add a few thoughts here with the hope that this will bring a bit more clarity to the decisions made on scripting in Rhino:
Brining Rhino Geometry to Python Devs: There does not exist a single solution that works for everyone. I agree that bringing Rhino geometry to python users is an incredibly powerful approach. But we can also get the same feedback from dotnet developers that want to use newer C# language versions and dotnet runtimes. We can throw other tools like Revit in this mix as well since just like python and C#, they are also environments that Rhino geometry can be useful in.
Rhino.Inside project is a great framework that satisfies the use cases listed above and more. It works inside standalone python 3 and dotnet programs as well as any other application that is willing to load Rhino using this framework into its process and use the geometry engine and plugin ecosystem that Rhino and Grasshopper are famous for.
Although the python library has been created a while ago, as @scottd shared an example of using this library in python above, it is still working in the latest python 3.13
Bringing Python to Rhino Users: Not everyone is comfortable creating python virtual environments and projects in vscode or other IDEs. For this reason having an easily-accessible script editor inside of Rhino and especially Grasshopper is necessary. They make scripting more approachable to Rhino users. ScriptEditor in Rhino 8, takes care of installing and preparing a python 3 environment inside of Rhino very easy. I know that it is not the best and greatest python 3 out there, but it does work and it does bring the power of scientific packages like numpy and pytorch inside of Rhino. This works for a lot of Rhino users. Embedded script editor also benefits from running in the same memory, is able to access just about anything in Rhino, and is acutely aware that it is inside of Rhino so it can provide Rhino/Grasshopper-specific features.
Support
I am one of the primary script-editing developers at McNeel and you probably have seen me discussing python and scripting on the forum in the past years.
I understand that you feel the rhinoinside python package is âabandonedâ. I would love to head about any bugs or errors that you are seeing that stops you from using any of these libraries, or the script editor inside of Rhino. You can always directly tag me on any of related issues.
2 Likes
Thank you for the thorough explanation here, very valuable feedback.
I started Rhino from v4 around 10 yrs ago, and experienced the up and downs of âparametric designâ.
IMHO, though Rhino started as a NURBS modelling software, but most scripting / programming based task are related to polylines, meshes, etc. So the strength of NURBS or Industrial Design doesnât apply as much here.
Given this, other software like Blender has much stronger support on Python functionalities and are free. And if not because of Grasshopper, I myself may also migrate to Blender for programming tasks.
And most importantly, when you do heavy computation, thereâs no way to kill it without killing Rhino, and no clue where the problem is (the debug function in ScriptEditor is not very useful in this case, as the whole Rhino session is freezed) â this is very frustrating.
Iâm not saying you should abandon the native scriptingEditor, and Iâve seen improvements from v7 to v8. But comparing having a tool inside Rhino, I would expect if someone really want to start serious scripting, he/she would prefer a more integrated workflow with modern Editors (+plugins, auto-completion, type hint, linting, etc.) over a âOK-to-useâ editor, especially when the project goes big. With the native ScriptEditor, youâre basically saying âNOâ to all the features enabled by modern editor system â It is not possible to maintain a large project with the current native ScriptEditor.
It really depends on McNeelâs goal here â Do you see python as a first-class citizen or just some supportive tools in Rhinoâs eco-system?
If you want to attract more users and nurture the programming community, embracing the major Python community seems to be a MUST (Think about why MS developed the VS Code).
Letâs say, for instance, type hint, multi-threading and multi-processingâŚ
I tried it 1-2 years ago, and abandoned it due to some strange issues I encountered with Python 3.11.
Additionally, performance-wise, the Python3 editor even cannot compete with the IronPython one:
Even I use concurrent.future for multi-threading, it is still much slower than the single-threading version of IronPython2.
I havenât made tests outside Rhino, but I would assume the comparison above shows sth critical in your implementation of Python3 ScriptEditor in Rhino 8.
This is a wrong comparison.
The only reason why IronPython exist in Rhino is because C++ is wrapped to .NET and IronPython is .NET version of Python. This cuts a lot of possibility.
This whole process complicates the work:
- no CPython libraries numpy, scipy were available
- your example probably can be faster using native CPython, depending how you write your code
- installation of libraries
- C++ and Python integration was convoluted
- whole editor and coding experience
I guess at that time Python was not so user friendly but with current 3.9 - 3.13 versions you can do a lot of things and the community is very good. I was always asking myself a question why you should write in ironpython when you could use visual studio and c# in Rhino. Compiled code will always be faster. I only changed my opinion with CPython.
1 Like
What is wrong? Please be specific.
This is just a simple mesh processing script, that use some native Rhinoâs mesh methods.
These methods doesnât exist in CPython.
If McNeel provides such script editor and claim it to be more âupdatedâ, then at least the performance should be the same.
The reason for python is simple â .NET is not a good product for numerical operation or data processing. It is a product by MS mainly focused on desktop software, and geometry / data processing stuff is very limited, compare to the Python community.
I develop GH plugin with C# (plus some cpp code ported to C#), but for simple data processing, Python is fast for scripting. Though with the ScriptEditor, developing experience is not that smooth.
Do you realise that the ironpython workflow is not really python workflow?
Ironpython is used in Rhino because the software decision was made towards .NET.
I think it was a historical decision made with available wrapping tools at that time.
If you try not to use Rhino and just work with python only you would see the workflow a bit clearer.
I would not be surprised that the speed differences you see, is only temporary, because of ScriptEditor that is getting better every day.