Python support please?

[SoNewBee]

Can we add python support to u3d?We can use python as the script of u3d rather than AngelScript because AS is really difficult to learn.I think that could be more convenient to noobs and popularize u3d. Besides,python should be easier when we want to implement something need multi-thread(like DirectX11,it can implement multi-thread rendering at a high level,of course the efficiency can not compare with Vulkan,but it can also provide us more convenience if u3d support Vulkan in the future) I think we should keep pace with the times since we separated from urho3d.Maybe we should just abandon AngelScript because the difficulty of AS just like C++,but the performance of it just like lua and the coding efficiency of it is too low to compare with lua.

[SirNate0]

I am definitely in favor of adding support for Python, and have started some work on it in the past.

That said, I do think a few of the benefits may not quite live up to your expectations:

Besides,python should be easier when we want to implement something need multi-thread

I may be mistaken, but I believe even the most recent versions of CPython use a Global Interpreter Lock that reduce the utility of using python for multi-threaded code.

---

To reiterate, I do support adding Python. But it also requires a few questions to be answered:

• are we embedding a Python interpreter in U3D?
  • Does this interpreter allow using external modules, and how?
  • Which interpreter (CPython, MicroPython, something else)?
• or are we making U3D into a Python module?
  • What would a game look like then? Does the U3D user pack a Python interpreter and the necessary modules into an installer?

[klaussilveira]

With Panda out there, does it make sense to have U3D as a module?

pybind could help with making Python an additional, optional, scripting option: https://pybind11.readthedocs.io/en/stable/advanced/embedding.html

[SirNate0]

I think it might make sense as a module in that even if the interpreter was embedded, the cleanest way to interact with the bound code is probably as a module. Similar to blender's bpy. Though I'm not convinced that "download U3D module and use from python after installing with pip" would be an ideal way to interact with the engine...

Agreed, pybind11 is pretty great, it's what I used when I was working on my attempt at the bindings:

https://github.com/SirNate0/PYrho3D

[SoNewBee]

I am definitely in favor of adding support for Python, and have started some work on it in the past.

I am glad to see that we share common view. Well,I think it won't be so complicated. We just need to make the editor of u3d supports python and be able to give us code completion according to u3d's API.We just press "F5" then the programs will run.It is in the same way as godot supports gdscript.

are we embedding a Python interpreter in U3D?

No,I think we u3d should be light-weighted and easy to use like godot. Users of u3d shoud install python by themselves.It is not something difficult.

I may be mistaken, but I believe even the most recent versions of CPython use a Global Interpreter Lock that reduce the utility of using python for multi-threaded code.

Yes,it is a problem for now. But we can have a look at this:https://peps.python.org/pep-0703/ (PEP 703 - Making the Global Interpreter Lock Optional in CPython) I keep optimistic for this.😄Besides,python can be accelerated by many ways(numpy,numba or other something).

• Which interpreter (CPython, MicroPython, something else)?

Maybe CPython?MicroPython...I don't know it very well. One thing I am worrying about is that whether android will be supported when we use python as the script of u3d?Maybe we need an "export template" like godot？ Anyway,I am glad to see that this suggestion can be accepted.Maybe this is the embodiment of u3d's creed:"Do not reinvent the wheel. Engine should reduce development time. Less yak shaving, more game making."I like this creed.

[SirNate0]

Users of u3d shoud install python by themselves.It is not something difficult.

That's fine for direct users of u3d, i.e. developers. But I don't think that's an acceptable solution for the end-users, i.e. the gamers. While many of them are certainly capable of installing Python themselves, no one really enjoys having to manually install dependencies for software on their own. It's a slightly different scenario if the goal is to ship some sort of software using U3D for simulations/visualizations (maybe for some scientific or robotics code or something) as a python module - then the end-users having to install python would make sense, but the software is probably not a game in that case and it's probably installed through PIP (and not Steam).

We just need to make the editor of u3d supports python and be able to give us code completion according to u3d's API

"Do not reinvent the wheel. Engine should reduce development time. Less yak shaving, more game making."

U3D's editor doesn't really support editing code directly (at least as far as I am aware), it's more for the scene layout. Supporting Python in the editor would basically be the same as is for Lua/AngelScript - add a PythonScript component and add support in Urho3DPlayer.

In the interest of not re-inventing an IDE, I don't think the editor should ever really become a code editor. Since the developer uses their editor of choice to edit and run the code, it's really more on the developer's choice of IDE in providing support for code completion and such.

MicroPython...I don't know it very well.

Here's the documentation, but basically it "aims to put an implementation of Python 3.x on microcontrollers and small embedded systems" (with ports for desktop OSes as well). So it should, in theory, be more lightweight than CPython, though at the cost of not supporting the vast network of libraries available for CPython. I favor CPython for that reason, and perhaps more significantly, because pybind11 exists. The only reason I even think about things like MicroPython is that in my own project I have a lot of things where I basically want to be able to write a line or two of code/math and have that interpreted with a specific limited set of variables available, and multiple lightweight script interpreters would be one way to accomplish what I want.

https://docs.micropython.org/en/latest/develop/gettingstarted.html#building-the-unix-port-of-micropython

[SoNewBee]

U3D's editor doesn't really support editing code directly (at least as far as I am aware), it's more for the scene layout. Supporting Python in the editor would basically be the same as is for Lua/AngelScript - add a PythonScript component and add support in Urho3DPlayer.

In the interest of not re-inventing an IDE, I don't think the editor should ever really become a code editor. Since the developer uses their editor of choice to edit and run the code, it's really more on the developer's choice of IDE in providing support for code completion and such.

OK,then we don't "re-inventing an IDE" or re-invent the wheel.But I think we should make the wheel/editor more completely. I think the design of the editor and the way we manage u3d's project need to be changed.We need an editor which can add script to a specific node by clicking right mouse and choose "add script". For example,we can set the parameters of camera,then we can make the camera more useful by clicking right mouse and choose "add python script". The script we added to the camera can inherit all the settings we have done to the camera in editor automatically. We can do the same things when we want to add script to a model node or other something. Then we can run python code in VSCode/Pycharm or other something by press "F5". This will be very convenient to us.Think about it: we need not to build the project by cmake over and over again.I think this is a necessary function to an editor/engine,even if we don't write code in editor.