Okay, assuming youāre advising to an inexperienced nooby one, then what specific steps do I need to take on the CPython path? <
And after all, what should I do then?
Okay, assuming youāre advising to an inexperienced nooby one, then what specific steps do I need to take on the CPython path? <
And after all, what should I do then?
If you have access to Rhino 8 WIP, and Itās ok to work on a dev version, then go for CPython and the new editor. It supports pip and numpy and tk
If you stick to Rhino 7 or older, or you need to make sure itās a stable Rhino Release, or you want to support an older Rhino version, go for Iron-Python or C# and use numpy-alike library like "Math(.)Net "
In my opinion, this is the most straight-forward thing to do.
I wrote it because we had a large user base using the legacy RhinoScript language and this was an easy way to transition away from RhinoScript and into python.
Worked for me : Recoding legacy RhinoSycript code into rhinoscriptsyntax was a big part of my journey into python
Itās not dead, itās pining for the fjords.
Iām well aware of IronPython history, but declaring it āofficially deadā is a false (or at least polemic) claim.
Iām not sure I ever stated anything to suggest otherwise.
Assuming it doesnāt mean significant loss of functionality and performance from IronPython (e.g. being able to easily/natively implement .NET, RhinoCommon, Grasshopper API), I donāt see why not. I do however worry that (as with all new technology), this likely wonāt be the case. Which would negatively impact the creativity and productivity of myself and my team, as computational designers that work predominantly in GHPython (which, minor kinks and nit-picks aside, is a wonderful and mature platform at this point). So, instead of a hard switcheroo, Iād prefer natively providing both Pythons (ala how Dynamo is doing it), however āmessyā this might feel. At least initially.
VB right
We are continuing to support IronPython in Rhino 8. People can choose which language they want to work in be it C#, VB, C++, or python. When it comes to python you will be able to choose which implementation you want to work with. There will probably be some bumps in the road as we start supporting cpython and weāll fix things as we run into them.
Have you tried running the script? It may be that numpy has not been installed yet and I believe this happens the first time the script is run.
In fact, Iāve tried it a hundred times already, with many different spellings of the magic ā# r:ā and ā# requirements:ā tags, but to no avail.
So I had to resort to the last trick - the miracle of dancing with a tambourine around the PC and the use of psychedelic fumes. In this state, the great secret of the savannah was revealed to me:
for those unfortunate people like me - I took the following steps ā¦
go to the folder where the rhinocode environment is hiding, in my case it is *c:\Users\MainUser\.rhinocode\ cpython-1.7\3.9.6\Scripts*
Run āpip install numpyā manually.
And yes I confirm, Numpy does work with Rhinoceros (although I myself did not believe in it until the last moment), here is the proof:
I should have stated that this is my impression, but still the claim is not polemic at all. Microsoft dropped it and besides the popularity of CPython; IronPython and IronRuby did not find company-backed support. Instead, a small group of community developers worked on it further. Community work has often a bitter taste, because nobody is really responsible for fixing issues and finalizing a product. One of the largest concerns with Ironpython was the deprecated syntax. Finally, in 2021 the updated that, but in my opinion itās too late. C# and Visual Studio has evolved so rapidly, that I would not miss developing .Net code with all the features you nowadays get from the combo.
Besides this, C# and CPython are basically my strongest languages, and I feel mixing both worlds is just not a good idea. Why do you need interfaces in Python for? That is a redundant language feature for a dynamic language with a different way of class inheritance. If I would only know IronPython, I really would struggle to understand the purpose many things. On top of this, you can not fully write .Net code with IronPython. There are simply language features which are not covered and which are extremely hard to come around. Maybe this has changed yet, but if I remember I had issues in declaring volatile fields, async-await syntax etc. Which is really a problem for parallel and concurrent programmingā¦
@TomTom, @AndersDeleuran I am tempted to say āstop this, itās sillyā but the background discussion is interesting so instead please see this podcast from around 17:42 for the most āofficialā take I can think of for all this, from Pythonās creater and former BDFL
https://talkpython.fm/episodes/transcript/339/making-python-faster-with-guido-and-mark#play-at
Iām simply pointing out false claims that discredit peoples hard work. And raising legitimate concerns about switching out one technology for another willy-nilly. But yes, itās off-topic, and I shouldnāt have taken the bait
This sounds like a bug that needs to be fixed. I logged the bug at https://mcneel.myjetbrains.com/youtrack/issue/RH-66335
I was having trouble staying with straight facts in this thread as well. Tom is providing his opinion which is fine and his own. It is also not my opinion. Too much of this and weāll head down the path of tabs versus spaces discussions thoughš
Usually I mark my opinions. But there is no rational discussion about technologies possible and even the solution to this thread is opinionated. I was never a big fan of IronPython(not Python), that does not mean I discredit the hard work of the IronPython community, but you guys have to admit that community work has a lot of drawbacks and went through a lot of troubles. And IronPython is not super popular. It remains a niche tech. What majority of people like to see if they want to code in Python is CPython. So you are doing everything right. There is absolutely no reason to feel offendedā¦
I want to delete my post about IronPython, but discourse donāt let me do thisā¦ This is such a garbage. What am I doing hereā¦
spreading lots of knowledge, for sure!
No matter what interpreter we use, we still need to support interop with grasshopper which is written in .NET. Weāre switching libraries for performing this task from IronPython to PythonNet when running in cpython. There will be oddities in this system as well.
Dito
giving your valuable oppinon that makes others reply and seems interesting to many people like myself. thank you!