Does GDscript really have to be its own language?

[NovaDC]

First off I want to say that the features and effort put into GDscript makes it a nice language to work in, and having a more forgiving language with duck types and a language that's as responsive as it is in the Godot editor is a wonderful tool to have. I by no means have a problem with GDscript as it is.

But like, why is gdscript its own language?

I believe that Godot 2.0 supported some form of modified python in the past, and I can't help but wonder why exactly this was dropped. I understand that node based scripting was also something introduced in a later version, and that static type hints became much more efficient, but was their any other reasons that this change was made?

I'm asking out of morbid curiosity here, but what if Godot were to take a python parser (perhaps something more lightweight, like micropython instead of the vanilla runtime) and attempt to retrofit it into a GDscript sized hole?

Then Godot (and other smaller tool maintainers) would not have to maintain a proprietary language with all it's features and a whole ecosystem of tools, but instead focus on only applying a already quite similar language with existing support and fixes being applied to it. Then both novices and experts alike will have a easier time dipping their toes into Godot, and tricks used in python can allow for much more flexibility without having to request that already existing python feature be added to GDscript.

Python feels like a already well rounded (well, perhaps a little to well rounded for use in a single application like Godot) language and using a propitiatory language, even while it's syntax is so similar to python, make me think of things like BOO script with unity. I feel there might be an argument (though perhaps not a winning one) that a modified python parser could become the main language for Godot in a far future stable release (6.x, maybe even 5.x ?). With similar syntax, the parser could even sport a backwards compatibility mode, looking for a @gdscript(4) tag at the start of a file to add alternate definitions for some of its keywords (such as def -> func) and parsing rules (such as handling the class_name and extends declarations at the top of a file) to allow for GDscript's to receive support.

Honestly, a similar argument could be made for other runtime parsed languages like javascript, though the difference in formatting and - however types and objects work in JS (I am by no means a javascript or typescript dev myself) - could make it a less sensible pick for replacing a language like GDscript.

Of course, this is a discussion for a reason, while I could this as a handy feature one day, I also know that I don't entirely understand why exactly GDscript was made in the first place, nor the entirety of the repercussions doing something like this would have. Would trying to do something like this really be worth it if this could be (and already is) implemented as an addon? I tried to look up some past discussion about the switch from python to GDscript but either due to my incompetent research or it not being properly archived or published, I couldn't really find any official discussions about this. Also, I feel like a conversation like this could also apply to future discussion relating to modifying / changing the main language of Godot.

[AThousandShips]

I believe that Godot 2.0 supported some form of modified python in the past

It never did

using a propitiatory language, even while it's syntax is so similar to python

GDScript isn't a proprietary language in the general sense, it is open source, do you mean a bespoke/in-house language?

But like, why is gdscript its own language?

I'm asking out of morbid curiosity here, but what if Godot were to take a python parser

GDScript isn't Ptython, it is it's own thing because it has specific needs

Making it more Python like would make people more confused than they already are assuming GDScript to work like Python, it's also a lot of extra features to make it compatible with both, it would also make tutorials confusing

[NovaDC]

Oh, I thought that older versions used the .py extentions for scripts. I can't find the place I saw this first so I suppose I confused some mention of older python scripts for godot 2.0 to mean that they were used in a project using the engine instead of them just being used in the engines repo as tools. I guess that explains why I never found anything about that :P. I considered GDscript a proprietary language (personally) as its a language used for only a specific application. I thin in-house might be the term to use, I thought a proprietary language simply meant that the language was specific to a single piece of software and saw little use outside of that context. I can see how a change like this calls for a update to all examples, which of course isn't something to brush off, thought the toturials could add python as another language tab to switch to, allowing for existing toturials to remain. When it comes to confusing python users more, is that saying that the godot api in python would be have to be implemented in a way that isn't already common in python, or is that saying that a compatibility mode for gdscript would be the confusing factor? Is it something else? Also, what other features of python or gdscript would make this swap harder? I'm morbidly curious about the reprocussions a change like this would have on the engine.

…

On Fri, Mar 21, 2025, 2:21 p.m. A Thousand Ships ***@***.***> wrote: I believe that Godot 2.0 supported some form of modified python in the past It never did using a propitiatory language, even while it's syntax is so similar to python GDScript isn't a proprietary language in the general sense, it is open source, do you mean a bespoke/in-house language? But like, why is gdscript its own language? I'm asking out of morbid curiosity here, but what if Godot were to take a python parser GDScript isn't Ptython, it is it's own thing because it has specific needs Making it more Python like would make people *more* confused than they already are assuming GDScript to work like Python, it's also a lot of extra features to make it compatible with both, it would also make tutorials confusing — Reply to this email directly, view it on GitHub <#12043 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BHEZPQ4QL2L6A66HZK5YGK32VRRFFAVCNFSM6AAAAABZQUV5CWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTENJYGEZDQNQ> . You are receiving this because you authored the thread.Message ID: <godotengine/godot-proposals/repo-discussions/12043/comments/12581286@ github.com>

[AThousandShips]

I'd say it would be more interesting to get some clear arguments for why this would be beneficial, what it would bring to improve things, other than making it easier to use for people used to Python

I'd suggest actually looking into how GDScript works to see why it would be difficult to accomplish, it's hard to explain to someone not familiar with how GDScript works and how integrating a language into it works

But this seems to be based on the incorrect assumption that GDScript ever was Python, which I'm not sure where you might have gotten from, it kind of removes a lot of this idea

[theraot]

I have some ideas of where you could have gotten the idea that Godot worked with Python:

• At some point I saw people used to ask about GDScript in Python Q&A sites, aside from the syntax being similar to Python, this was because there were too few options for GDScript specific questions, and people hoped this would help them get an answer... And it would get them an responses assuming it was Python - which of course - usually didn't work.
• And Godot can be extended to support other languages, including Python (there is an extension on the asset library for that, although I don't know its current state). You might have seen a demo using that, or have seen it mentioned in some discussion.

The languages are different. Python is much more dynamic than GDscript, and by that I mean first that you can expand and monkey patch objects, which you can't in GDScript... And second that GDScript has actual types (including int and float) not just type hints. So semantically GDScript is closer to Java or C#. Python has other features, for example list and dictionary comprehension that do not exist in GDScript. Also, GDScript assumes there is an scene tree and an inspector and Godot's life cycle, and has language features to use them: node paths, export and onready annotations. All of that is alien to Python or any other language and would require to introduce more idiomatic solutions.

Know that making GDScript compatible with Python does not only mean implementing any features that Python has that GDScript does not, but it would also mean supporting Python libraries, and keeping up with new Python language features. It is also not worth adapting Godot from GDScript to Python given that GDScript is designed to integrate with Godot, and changes in Python could become a source of bugs in Godot.

If you are looking to use Godot with Python, have look for the aforementioned language plugin. On the flip side if you want to make games with Python, then consider if a Python specific solution is better for you.

None of this is to mean that learning Python before learning GDScript is a waste of time. Variables are variables, methods are methods, classes are classes. The syntax is different and not every language feature is there, and there are other languages features to learn, but if you can think your way through implementing and organizing your code in Python, you will find that it is not much trouble to adapt to GDScript. Similarly, this is not mean that you must or should learn Python first. Aside from object oriented generalities and whitespace, GDScript and Python are also similar in that both are good first languages.

[Calinou]

I remember reduz discussing at some point that he could have made GDScript's syntax closer to Python, so that it's easier to port Python code to GDScript (e.g. using def instead of func for functions).

However, it's not a perfect solution, as having two languages that are very close to each other but not the same can be the source of many pitfalls. For example, if you post code online without indicating which language it is, it will be very difficult for syntax highlighters to detect whether you've written Python or GDScript code. It can also be confusing for users who happen to be using both languages (especially in the same project) if subtle behavior differences persist between both languages.

If you've used an alternative Python implementation like PyPy, you've probably experienced situations where some piece of code will work fine on CPython (the reference implementation) but not on PyPy. This is particularly common on larger projects that happen to be using dynamic functionality that doesn't map well to a statically compiled language – PyPy tries to encourage this as much as possible for performance reasons. This is the kind of situation that would be commonplace if GDScript tried to follow Python as closely as possible, to the point of gaining compatibility with a subset of existing Python code. Having an entirely different language prevents this kind of confusion.

There could still be some benefit in having a community-developed tool that converts Python to GDScript (or vice versa), but this is nontrivial to implement for complex projects. Similar efforts have been done for GDScript to C# and it's within the realm of possibility now that GDScript can be written with heavy static typing, but I still expect it to be a large task.