Future updates to Python in Rhino 3d

I recently started learning this and use it at work. :frowning:
If anyone knows a way to hack VBA such that I use Python syntax instead, please share this treasure.

:slight_smile: another thing I didn’t know it exists.

:thinking: this smells like the next python distro “Rusthon” :smiley:
Maybe that’s why there are so many programmers using it, re-writing python interpreter in Rust :stuck_out_tongue_winking_eye:

Oh, and @TomTom,

the only reason I bought my Rhino licenses was because of Python Engine being embedded. GH was also a stimulus, but mainly Python.

Nope. pyoxidizer or https://rustpython.github.io/demo/

1 Like

I think you should reread my messages, I’m not against Python, I just think that IronPython is not a well-thought concept and I don’t think its good to rely on defacto legacy code.

(BTW, You don’t need VS to write C# code, and the installation package will just be about the same size as the Ironpython distritibutions are. Core will soon even allow you to truncate assemblies based on the used imports, making everything even much smaller on deploy, without any need to install additional frameworks. )

Oh I indeed coded both languages Python and C# in Notepad++ without much coding assistance. I find it equally hard, of course Python lets you write faster then, but this is no argument. I don’t want to be the Lucky Luke of Coding, nor I’m about to start a C# vs Python fight. This really makes no sense and is highly subjective. Of course any language you know best is your favorite. Would be odd if not…

1 Like

I know you’ve used Python Tom (@TomTom) , and not starting a fight either.
I merely pointed out things you said you didn’t understand.
“Why they implemented IronPython (.net with python syntax) or would look into implementing CPython.”

This is the perspective of a novice programmer.

Rubbing the {, } and ; off my keyboard, declaring every single thing gets in the way of the thought flow when prototyping. Which is pretty much what python is used for.

Neither would I have continued to use Rhino (I work mainly with CATIA), nor would I have learned as much as I know now about programming and using an API if it wasn’t Python’s integration in Rhino. It is not so much a personal preference. It is the learning curve, readability, ease of use, portability (yes I keep saying that because you don’t need to install anything to use Python. Plug-n-play :wink: )

I use portable versions of CPython and IronPython, no install, no Administrator user requirements. Plug my FlashDrive or ext.HDD into any PC and make it your dev environment.

1 Like

I would say being picky about a language is the perspective of a novice programmer. All my workmates doing programming, including myself, can at least speak 3 languages and one of them is at least a C style language. If you have a framework full of elements being used by strong typed languages, then using a dynamical typed language for it is not making anything faster or better. This is one of the points. And this is my argumentation. The absence of {,} ; is no indicator for clean and readable code, which is another point. I’m out…

2 Likes

Well it kinda is.
I also work with other typed, alas scripting languages. VB(A), EKL, and I have to read a lot of csharp while using IronPython. Still python is most readable.

It is completely different thing whether readable code provides better performance. Obviously not. And here comes your best argument which I cannot argue about. But Python in Rhino is not there for performance. It is about bringing these people on the edge of the pier afraid to jump in the programming ocean. And c#/java/c/c++ are scary sharks. While the little snake is welcoming. :wink:

1 Like

Seems getting off-topic here. The point is - IronPython is practically dead no matter all the “announcement” of its rising. Started learning C# as the best future proof option. Open source, big community, excellent tooling, lots of sources to learn, versatility and a major CAD programs have .NET API with lots of C# samples (at least that I’m interested in). At first I liked python the most, but now I’m getting used to C#:heart_eyes:

This is so tiring. People are different. If you don’t like (Iron)Python, that’s fine.

Now move along, please!

6a794a8343b92ef76ccf1cb8fd0a8aec4768a161_hq

Simplicity

“This is the single biggest reason for beginners to learn Python. When you first start with programming and coding, you don’t want to start with a programming language which has tough syntax and weird rules.”

Quote from https://dev.to/javinpaul/why-every-programmer-should-learn-python-in-2019-157i

And I could not agree more. If I had to start with nerdy C# then I would never have started. Simple as that. Python was appealing and easier for my brain to remember between sessions. As a designer I only need to code every now and then so simple and easy tools that don’t require daily use for the brain to comprehend and remember was and is cruzial.

1 Like

Joke

A Python developer, a PHP developer, a C# developer, and a Go developer went to lunch together.

OMG what happened ???

They had a nice lunch and got along fine.

3 Likes

yeah, and now I’m the fanboy? This is hilarous… A fanboy is a person who is worried about the future of IronPython because the project doesn’t catch up with the development, but shows no effort in adapting to alternatives. Even worse such a person demands more work from other people because of his preference to one particular language and refuses to learn alternatives. I’m not speaking of C#. Modern dotnet allows you to choose between VB,C++,C# and F#. C/C++ and C# are two complete different languages bytheway.

I wasn’t replying to you. Also, that was a silly meme, apologies if it struck a nerve :wink:

2 Likes

“Readable” code is more dependent on the author than the language. Many people can write completely unreadable code in any language.

We will continue to support all of the languages that we currently support in Rhino. Support for different python runtimes is not a matter of replacement of one python for another. We can find ways to add support for additional runtimes.

If you want to use CPython 3 and Rhino, you can do so today with the ‘rhinoinside’ project. Rhino inside Python

6 Likes

Thanks @stevebaer for bringing the discussion back to constructive terms.

CPython + RhinoInside is an absolutely fantastic project. I would love to see more examples of usage, because some things are not entirely clear to me (some are very basic, like, is it possible to access the active rhino doc from CPython+RhinoInside?)

2 Likes

Because there was no other interface made available. Rhino’s kernel was written in C++ and only made accessible via .NET, probably because it was considered ‘modern’ 10 years ago. Look how well Houdini and SideFX’s build of CPython performs. Python 3 in Rhino is a must-have!

1 Like

.Net still is modern. At least it makes a lot of people easily, earning a lot of money. Even C++ does.
I really hope you can say this to professionals using Houdini, SideFX as well. As a matter of fact, many Python applications are migrated to .Net or C++ once they reach a mature state. Thats not making Python bad at all, I support Python 3 for Rhino as well. Its a great language, such as many others. But its not language Nr.1 and therefore a must-have… or what all fanboys always want to say with such statements

Will RhinoInside allow you to write Python 3 Grasshopper Components? Is this something that will be added?

RhinoInside is still using PythonNet clr class to access the RhinoCommon. Behind the scenes on Windows it appears you are going from C++ -> Exported C Wrapper -> C# Wrapper ->Python. It would be nice if python was embedded as a first class scripting in Rhino using the standard Python embedded methods, as well as being able to be a GH component. Is this something that might be seen in the future?

How would that work without access to .NET? Grasshopper itself is .NET so how do you propose accessing it from python with “standard embedded methods”?

Either the methods below:

https://docs.python.org/3.7/extending/extending.html
https://www.boost.org/doc/libs/1_62_0/libs/python/doc/html/tutorial/tutorial/embedding.html

Seems like ctypes and CFFI would be going down the same path you are now.

In the case of the GH component .NET would call Python, but the Python would not be calling .NET unless it was required.