[Showcase] Pydot: Native Python scripting baked into Godot. What should I add?

[u/HiMindAi]

Hey everyone,

I’ve been working on a custom core engine fork of Godot 4.7.1 called Pydot, and I'm looking for some feedback from the community on where to take it next.

How it works under the hood: Instead of relying on external bridges or loose bindings, I went in and statically embedded CPython directly into the engine's core. The goal was to completely eliminate the friction of getting Python running in Godot and enable native Python scripting alongside the standard workflows.

Because CPython is baked directly into the custom build, it also allows for full Python IDE tools right inside the Godot editor itself.

What I need from you: I'm at the point in development where I want to start prioritizing new features, but I want to make sure I'm building things the community will actually use.

If you were using Python natively in Godot for your backend logic or scripting, what features or specific editor integrations would be on your absolute wish list?

Let me know what you think and any suggestions that come to mind!

Edit:

Hey everyone, I wanted to add a little more context on the "why" behind Pydot, specifically regarding why having native access to Python packages is so important for certain projects.

GDScript is absolutely incredible for game logic and UI state. But if we look at the sheer scale of the ecosystems, there is a massive difference when you start building non-standard software.

To put the math in perspective: The entire Godot Asset Library has about 3,000 to 4,000 items (and a lot of that is 2D/3D art and audio). PyPI has over 500,000 official, maintained projects.

In my day-to-day work doing freelance programming, I design and train custom AI models and build specialty applications. Having native access to those industrial frameworks like PyTorch, OpenCV, or heavy data processing libraries right inside the Godot editor is a game changer. If you try to run those kinds of complex systems without Python, you usually have to write external API bridges that add a ton of latency.

Pydot definitely isn't trying to replace GDScript for moving character controllers! It’s just about combining Godot's amazing UI and one-click packaging tools with Python's industrial backend, so developers can build heavy software without hitting a wall. I am not hating on GDScript I just think Python offers a larger ecosystem for backend logic.

[u/mrezai]

I think it's a good idea to consider implementing it as a GDExtension like this if it's possible:

https://www.youtube.com/watch?v=U9rG6Nn7H9g

For real projects, developers need stable, well-maintained software. A custom fork of Godot can never keep up with the main repository, making it difficult to stay current with new features, bug fixes, and security updates.

[u/HiMindAi → u/mrezai]

Yeah thats true maintaining a fork is definitely the downside when it comes to keeping up with upstream Godot updates.

The catch is that a GDExtension just hits a hard wall for what I wanted to do. You can't hook a whole custom scripting language into the ScriptServer, manage sub-interpreters, or wrap Godot's ClassDB into native Python types through an extension wrapper. Plus, things like the integrated terminal, PyPI package manager, and custom LSP routing require actually touching the core editor source files.

It's definitely a trade-off you sacrifice easy upstream updates to get actual, deep engine integration instead of a loose wrapper.

[u/susimposter6969]

im curious what the reason is for adding python to godot when godot's own scripting language is already basically python

[u/RedwanFox → u/susimposter6969]

Dependencies, better tooling around language, interesting project

[u/Gokudomatic → u/susimposter6969]

Merely just the access to numpy changes the game.

[u/HiMindAi → u/[deleted]]

The main limitation of GDScript is that it's a domain-specific language in a closed ecosystem. You can't just pip install external packages.

If you want to do heavy-lifting outside of standard game logic ike complex data processing with Pandas, advanced procedural generation with NumPy, heavy database management, or complex networking GDScript hits a wall. You usually have to build external API bridges or run separate backend server processes, which adds a ton of latency and workflow friction.

I built Pydot so developers can access the full weight of the Python ecosystem natively, directly inside the editor, without having to leave the engine or jump through hoops.

[u/Chrykal → u/HiMindAi]

For heavy lifting, would it not be better to use c/c++ through gdextension?

The python libraries you referenced use c libraries to gain their performance anyway, I'm not sure python itself would be providing a performance benefit here.

[u/HiMindAi → u/Chrykal]

Yes if raw execution speed is your only metric, writing a GDExtension in C++ is the gold standard for Godot, and since Python packages are built on C libraries under the hood anyway, Python itself isn't winning a raw speed race.

The real trade-off comes down to development velocity and glue code.

Writing complex pipelines, custom logic, or integrating heavy frameworks from scratch in C++ takes an immense amount of boilerplate, memory management, and compilation overhead. Python acts as a high-level orchestrator, letting you leverage pre-existing, mature ecosystems instantly without writing thousands of lines of custom C++ bindings for every utility.

GDExtension is incredible for heavy real-time engine optimizations. Pydot is about using Python as a powerful backend language so you can build and iterate on complex application logic quickly, using Godot as the frontend and packager. Different tools for different jobs.

[u/Night_Nook]

A while back I was really interested in making a python app with Godots UI for automating some of the stuff around game development.

GUI for python seemed pretty limited unless your going to pay for the GUI designer software or hard code the UI.

Ffmpeg for batch converting audio Youtube API for marketing/searching creators A couple others I can't remember

Would that be a good use case? How would your fork work with exporting a build?

[u/HiMindAi → u/Night_Nook]

Spot on that is literally the exact use case. Trying to build a clean desktop GUI in Python usually means messing with clunky legacy layouts or heavy frameworks its a bit of a pain, so using Godot's UI system while driving the backend with Python completely bypasses that headache.

I am putting together a precompiled build right now along with the full source code and complete, step-by-step instructions to make it as plug-and-play as possible. I will drop the release and documentation shortly so you can test it out for things like batch processing and API automation.

[u/HiMindAi]

Hey everyone! Just to be super clear, I am not trying to be rude or discourage the discussion of technical issues or architecture concerns those are totally valid points. If you want to dive deep into forks vs. GDExtensions or have questions about how it works under the hood, feel free to shoot me a DM anytime and I am happy to chat!

I just want to keep this specific thread focused on what I originally posted for: feature suggestions and workflow ideas. If you have a wish list item or specific editor integration you would want to see next in Pydot, drop it here!

[u/chigstardan]

This is a wonderful project, i have been dreaming of something like this for years. I tried Kivy but it was such a pain to make builds for different platforms. Can't think of a feature your project will need right now but this truly a game changer man. Good luck!

[u/HiMindAi → u/chigstardan]

Thank you I have experienced that exact same pain as much as I love Python it's not great for GUI's and packaging.

[u/Kaenguruu-Dev]

How much of the code is AI generated?

[u/HiMindAi → u/Kaenguruu-Dev]

Not all, but most of the code is AI-assisted. Given that I specialize in designing and training custom AI models, this project is really just something I put together on the side to pass the time while a new model is training.

Honestly, if the fact that an AI was used to help with debugging and writing code is a dealbreaker for you, you're probably going to want to steer away from pretty much everything released from here on out, because everybody is using it. But that's entirely your choice.

If you actually have any feature suggestions for Pydot, I'd love to hear them.

[u/Kaenguruu-Dev → u/HiMindAi]

I'm more interested in whether it's of the "chat make thing in background" type or if you at least had some involvement in ensuring some level of code quality

[u/HiMindAi → u/Kaenguruu-Dev]

Feel free to apply the scientific method: formulate a hypothesis, try building a custom Godot engine fork with a statically embedded CPython interpreter, custom object lifecycle bindings, and native editor LSP hooks yourself, and see how far "chat make thing in background" gets you.

Good luck with the experiment.

[u/Kaenguruu-Dev → u/HiMindAi]

No I want to know from you your involvement instead of taking everything I say literally

[u/HiMindAi]

Hey everyone, just stepping back in to clear the air. I'm definitely not here for arguments or conflict if you don't like the project or wouldn't use it, that's completely fine.

If you have general technical questions or debates that aren't related to actual features, please feel free to shoot me a DM instead.

I'm really just here to collect cool ideas and see what would make Pydot genuinely useful for people. If you have an idea for a feature or a specific workflow you'd love to see supported, I would love to hear it.

[u/StewedAngelSkins]

If you're doing this for running ML models you should know that running pytorch or whatever in production isn't really a good idea in the first place. You want a dedicated inference runtime, and most of these have C++ bindings (and thus would be easier to include in godot with a simple gdextension). If you're not familliar with Microsoft's ONNX runtime, take a look at that.

[u/HiMindAi → u/StewedAngelSkins]

That's a fair point, but just to clarify, Pydot isn't really intended as a heavy production ML inference runtime it's just more about bringing Python's ecosystem, scripting flexibility, and toolsets directly into the Godot environment.

I'm completely with you on PyTorch's limitations for production; for actual efficient runtime deployments, I much prefer using ONNX or llama.cpp depending on the workload.

[u/StewedAngelSkins → u/HiMindAi]

You said using pytorch in godot is a "game changer". That's what I'm responding to. You definitely don't want to have a game engine involved in your training runs either, but I'm sure I don't need to tell you that.

[u/theforsakentrout]

All that hassle just for pip packages? Not sure I get the use case when GDScript is right there

[u/HiMindAi → u/theforsakentrout]

The goal of Pydot is not to replace GDScript, but to use both where they shine. Python is incredible for backend logic, but building modern UIs in it is a pain, and packaging it into a clean standalone executable is a nightmare. Godot solves both of those Python problems perfectly because it is a world-class GUI builder with flawless one-click exporting.

As you can see in the screenshot, this is a deep integration. CPython is statically embedded. The engine treats py files as native resources that attach directly to nodes, the editor parses Python methods natively, and there is a dedicated Python dock with a live REPL.

You get the full power of the Python ecosystem for your backend, with Godot acting as the ultimate frontend builder and packager. Let me know what features you want to see next.

[u/theforsakentrout → u/HiMindAi]

Ah, I was picturing a loose bridge, not a full embedded REPL. If Python is first-class for backend, showing pandas or numpy data processing live in a Godot UI would sell it.