why no native python api?

Hi all,

I'm new to unity and the community, just signed up. I come from many years in the film vfx industry and now starting to poke around at what Unity can offer.

Python is the default scripting language amongst the usual suspects of 3D/2D applications and I am wondering why Unity3d has chosen not to pick it up? I've been searching for a native supported python api but I can't find anything. I find allot of post of people asking how they can wedge it into place but nothing officially supported.

From a little reading it appears C#, JavaScript and Boo are the chosen official supported languages. I'm wondering why python isn't considered? Is it a legacy thing or something based around the .net framework, I would have thought IronPython be a strong contender for this very thing? I can't see speed being an issue, python may be marinally slower but it makes up greatly in other ways.

There seems to be allot of native cross application work going on between Maya and Unity so I find it even more strange that Unity isn't picking up said syntax when it integrates so closely with maya infrastructure. Surely it isn't anything as trivial as a disagreement on design?

Really interested to know why if anyone can answer it.

Thanks,
Nick.

 

I can only speculate, only someone within Unity could give the real answer.

The compatibility with Mono is going to be the single strongest factor in play here. Skimming IronPython's site, one thing that jumped up at me:

Earlier version of Unity had an older version of Mono, and so there would have been a lot of caveats and gotchas when using Python in those versions of Unity. As the three scripting languages haven't changed since 1.x, it's possible that they simply haven't considered the possibility of adding another language since then.

Alternately, (and this is just a broad first impression), it doesn't look like IronPython is a big project with lots of support behind it like C# would have, and therefore may or may not be robust enough to be brought into Unity easily. If that snap judgment is even close to accurate, then supporting and maintaining it would involve a lot of manpower on Unity's end.

On the other hand, you can certainly say the same about "Javascript" (UnityScript), but they continue to maintain that; it's unlikely that IronPython would take more effort than JS does.

The second factor is, there simply might not be much (perceived, at least) demand for it. This post is the first I've heard of the possibility, for example, and I've been on the forums for... I dunno, 8 years or something?

Unity's integration with Maya is a non-factor here. Maya's ability to run Python cannot possibly be translated to Unity's ability to do the same in runtime. Unity can only do binary-level stuff with Maya if Maya is installed on the machine, and only in the Editor (mostly for that exact reason - because it'd be absurd to ask users to install Maya on their machines). For Unity to use Python, it must run within Mono, there is no way around that.

All that said, I don't want it to sound like I'm against the idea. You make some compelling arguments; if Python was implemented in Unity, I'd certainly learn it (working in an animation studio, I could foresee all manner of handiness coming from learning a Maya-compatible scripting language), though I doubt I'd use it as my primary language. More to the point, I could see it being really useful for animators who are familiar with it.

 

Hi there,

All valid answers, thanks for the insight ...very interesting. I come to the same conclusion in your js statement …I would have suspected no more resource allocation than what they may be currently applying.

As for my maya->unity crossApp comment. Sorry that was a little vague, it was intended to be more in the realm of user compatibility. There is a huge community of 3d py users writing an array of tools to extend their parent applications to which if unity are going to the trouble of integrating binary reads to allow for seamless asset transactions to at a guess attempt to capture a portion of the maya market share or at least entice them toward a unity end solution over another package …then I would have suspected that likewise the same be afforded to the scripted side of things for tech artists involved on the maya pipeline side. Using myself as an example …when I heard of unity, my first thought was, does it have a python api. Maybe that is an odd thing to ask first but for me I come from a heavily tool/pipe orientated background so to get my interest and allow me to dive directly into unity, an official api was exactly what I found myself searching for to see what I could get access to.

Cheers

 

Unfortunately, supporting multiple scripting languages is painful as is. Adding more wouldn't be a good idea and would only help to spread resources thinner. Every language we officially support has to have support in tests and documentation. Given that with maintaining our Mono fork and developing IL2CPP (plus a bunch of other tasks and things), our scripting team already has tons of work on their plate, things have to be considered carefully.

TBH personally I'd rather see us losing a language or two instead of gaining one

 

I personally would drop support for Boo.

 

I think lot of AssetStore creator would be happy if you would lose one or two.

 

When we all talk about losing two languages, we all know which one to keep. ;'p

 

Let's just not start another language-religion zealot war.

 

To be honest I think that'd be a great idea. I've personally never thought that "has multiple scripting languages" was a benefit.

 

Agree. Aside from the impact on development resources for us and 3rd party suppliers, I think having multiple official scripting language also helps splinter the community by arbitrarily creating divisions where there should be none. Think it's a little different if the options available are explicitly meant to enable very different kinds of capabilities but the current set is actually explicitly meant to do the same thing as much as possible.

 

Hi Rene... yes I can very much see your point. As it stands I am surprised 3 languages are actually officially supported ...Autodesk can barely support their 2! Unifying the scripting toolsets will be a very positive step in the right direction.

Thanks everyone for your comments... I certainly didn't intend to start a Windows vs Mac style debate ...coming from a heavily Pythonised industry that often pipeline integrates with applications such as Unity and finding a lack of support, I found particularly odd ...however in retrospect I think it has been adequately answered here, so thanks.

Cheers

 

I'd take anything over Boo, OR (what unity devs probably want is to) just get rid of boo and add more support to javascript and c#

 

Functionally, yes. This will sound cynical of me but... isn't it mostly about marketing?

 

Naw, I'm still waiting to see a single decision in the product that came about because of marketing concerns (*). The core group of guys who laid all the foundations for Unity are way too much techies at heart to care about that. I'm pretty sure it was more of a "Wat? We can support three different languages all on the same architecture? Coolio, bring it on, man!" kind of thing (I'm even pretty sure we all talked like that back then)

(*) Ok, well, the MMO thing does come to mind...

 

Fair enough. To be honest the main thing that gave me that impression is that one of the languages is called "JavaScript" despite not actually being JavaScript.

 

Frankly, with 10 years of experience and having shipped games or worked on almost a dozen different engines, I often have the feeling there is a distinctive lack of experience behind Unity's foundations. No insult intended.

I mean, I'm looking at version 4.5 of Unity, and wondering how much you've paid and continue to pay for mistakes made at the start, but that you keep dragging over. From my point of view, supporting three languages gives you nothing, but is most likely horribly expensive to maintain, and that's only one of the numerous design issues I've spotted in Unity.

 

The different languages didn't splinter the community in the beginning. The side by side worked very well for years. The splintering is a invention of a handful people here on the board. Up to the petition to make JS deprecated. That's at least my observation.

I wonder how much this is an official statement, and how much a rant from an employee that has not the full insight. Makes me wanna have an official statement now. Could somebody please ask David Helgason?

But interesting enough that even Unity employees wants to get rid of the one or another language. It's not so easy though. It's not that Unity JS is just used by a few enthusiasts. And even BOO has its usership. You would throw out lots of users when killing a language now.

As far as i know the decision to support more than one language was to catch as much possible users as possible from various ends. To provide an entry level for people coming also from other languages, and not just from .net. Which worked pretty well.

 

That's one thing we're not quite consistent on. We indeed use "JavaScript" a lot in documentation and marketing material whereas in development (and even sometimes in the docs like here) it is always referred to as "UnityScript" because, you like say, it isn't JavaScript.

I think it's far more complex than just a question of experience. No question that there's also things where that came into play (audio system comes to mind; we have two really competent guys addressing that) but I think other factors had far more impact.

As a programmer working on the codebase today, I find it very easy to spot many of its shortcomings and constantly find ways in which things could have done much better. But it's always easy with that kind of backwards-looking perspective. One has to keep in mind that

• a) there were a lot of innovations in Unity where the devs simply had to break new territory (asset pipeline comes to mind) and thus simply didn't have a lot to go on (heck, even component systems were something pretty new back then),
• that b) it's easy to analyze this from the position of safety now but in the early years, Unity had to make a lot of stuff happen very fast or go under so sometimes there were shortcuts taken for which we pay direly today (you always do) but on the other hand, we're still here, and
• that c) probably no one anticipated how big and pervasive Unity as a platform is going to be and probably no one even had the "platform-kind of thinking" but rather saw Unity primarily as simply a game engine, so some decisions turned out to be shortsighted in the end.

But you're right, we're paying for mistakes and, like every other software shop with a long-lived platform on their hand, we have a continuous battle on our hands with legacy from way back. But we're fighting it and I'm quite positive that things will get better and better.

The three languages thing, because of .NET and Mono, is luckily not *THAT* expensive to maintain. It's more of a not-so-wise usage of resources rather than something that impacts the platform as a whole negatively.

Heh, you'd have to ask David yourself But you're right, I'm absolutely just voicing (though in no way ranting) my opinion here ("TBH personally..."). Always do.

But it's all just discussion. There are no immediate plans to abolish anything or change anything here.

And I see your point and yup, the fact that UnityScript is in fact actively used and not just dead weight is definitely uncontested.

 

I'm sorry, but I'm looking at Unity from an eye of someone who worked on numerous engine that are not on the public domain, such as Jade, Anvil, Nimitz, Onyx, and many other, on top of those from public domain such as Construct, Unreal, Quake, Source, and so on. None of them were ever perfect, some were just plain horrible, but what I've retained from each is what was right, and what went wrong.

a) Component system... Jade was first written in C with C++ added later, and yet was component-based with a unique interpreted in-editor script that was translated into C for deployment. I find it funny that such translation is now on the table for Unity 5... 13 years later. Frankly, I find Unity very lacking in the component department. The lack of sub-component is a big issue. The composition pattern, from my point of view, is simply too useful to ignore. And don't let me start on Unity's serialization or polymorphism.

b) True, you managed to make it work, but it could have been a lot easier, and could still be a lot easier for you right now. I have a good guess of the time you must spend writing and maintaining custom editor... And you should not be writing any! The only part you should be writing is the scene gizmo.

c) I can imagine. I'm just wondering if you won't do like 3DS Max, and drag along a rotten core forever, never taking the leap of fixing the deepest issues. I'm looking at the upcoming GUI rework, and I spot so many basic mistakes; some I have experienced, and some I can extrapolated. The first one being using GameObject for every GUI component. This is a place where sub-component would have saved you ton of work and you have prevented turning the hierarchy panel into a mess.

The solution with legacy is sometime to dump it and rewrite it from scratch to make it better. Might be a lot of work for a few weeks or even months, but it's often the kind of thing that in a few years you will look back and go "Damn, I'm so happy we did that!". I'm sorry if I'm a bit harsh on Unity, but I've spent the last year basically fixing or working around some of its shortcoming. It's sometimes very frustrating to work days or even weeks just wondering how to do something while everything in Unity tells you you can't.

There's some very basic tools that I think Unity is lacking, which from my point of view, after all the time of Unity existence, should have been done a long time ago!

Copy/Paste/Drag-Copy


Inlining/Object Picker


Just to give a few examples.

Again, sorry, but I feel the 3 languages impacts the platform negatively too. I'm not even sure there's a way to have the 3 being used in the same project and talking to each other. You can do two with some special folder and build order, but I think 3 is still impossible. And even with 2, it's only a one way communication. Juggling those, or ending up having to rewrite bought asset can be a major pain! Luckily, most asset we bought so far were in C#. However, we sometimes get a US script and find out we have to rewrite it to fit with our other scripts. I don't think it's something that should ever happen.

 

Didn't want to insult you, sorry

But the opinion of an official employee is more than just an opinion. Because the employee represents the company with everything he does and say.

The for me important bit is that there are no official plans to change the language issue in the future. Thanks for this info

Imho it's the opposite. Having more than one language available is what made Unity big. It attracted double as much people as with just one language. And having more than one language is very common. In the open source communtiy for example just have a look at Ogre and Irrlicht. They have as nearly as much language wrappers than there are available languages. Even commercial engines like Unreal has more than one langauge that you can work with. Blueprints and C++. UDK had Unrealscript (or was it Kismet?) and C++. Acknex engine had Lite C and C Script. Even when this one was a transition issue.

And i still wonder why having different languages HAS to split the community. Why not let everybody use what he likes best?

Why not? There's nothing speaking against it, besides event order maybe.

Most of my plugins are C#. I write my code in JS. No problems. And i never needed to rewrite a plugin yet. But yeah, maybe i'm a lucky one

 

Bidirectional communication between two languages is currently impossible. If you want to call one language (omnidirectional) you need to use the build order, like placing that script in the Plugin folder. Now, where would I put the third language script so that the other two could call it? Not every asset exist in the plugin folder, and not every one works with one-way calls. Multiple languages can be a problem.

From what I remember, Unreal's UnrealScript was a high level language similar to what Unity does, while the C++ was on the core, which in Unity we don't have access. In essence, Unreal only had 1 scripting language. I've worked with an engine in C++, an editor in C# and a gameplay script in a custom language, but in the end, there's only one scripting language.

I seriously fail to see any point in multiple scripting language support. Right now, all three Unity's language does roughly the same thing; build a CLR library. The difference only being syntax preference.

 

The point is the usership. People are simply different. That's the reason why open source engines like Irrlicht has so much language wrappers. I can speak for myself that i would have most probably never learned Unity when the only choice would've been C#. JS made click to me where C# still scares me away.

Did misunderstand what you have meant with bidirectional. Apologies. Google made me a little bit smarter then. Mh, usually you don't really mix the languages in a this deep way where you really need bi- or even tri/omnidirectional communication. When you are used to one language, then you usually stay in this language. And as told, i use C# plugins with JS code just fine. Bidirectional communication can be an issue though. Agreed.

 

I think python actually is not really suited to unity dev at all, nothing against the language since i love python and use it a lot for working with Maya and web development. But unity relies heavily on the language being strongly typed, while python is loosely typed and uses duck typing.

Even something as simple as defining public attributes to be accessed in the inspector in python would be a pain since the editor would have no way of knowing what kinda input field to make, and if its accepting a object how to integrate it.

Compare that to c# where at lot of the information unity requires it can simply get from the strong typing and syntax of c#.

With python you would likely end up doing very un-python like things, or perhaps using a modified syntax to add static typing in. In that case you would end up with something like the whole unityScript vs javaScript problem.

If a language was to be added Java is prolly the best contender in my eyes, but that would seem rather pointless since C# and Java are very similar.

Im on the side of believing its better to have 1 language, less time wasted on tests and documentation for all of them, that can be better spent on 1 language or new engine features. Also less confusion in the community.

P.S. im saying this coming to unity from tools and pipeline creation, working 90% in python for years, and i just dont see it as a viable language for unity due to what unity wants and how python works.

 

That's the same as Javascript. In JS you can say:

Code (csharp):

1. var someNumber = 1.0;
2. var somethingElse = "now its a string";

And the compiler figures it out. I think it would work the same way in Python, wouldn't it?

 

@StarManta ya but unlike unity script there is no way to give a type to a empty variable, which is very useful when defining public attributes, that requires a special type.

A lot of people get around this in JS by using a syntax like this

Code (JavaScript):

1. var myVar : GameObject;

which python dosnt have.

 

You got it wrong, "var" is not a keyword of typeless container, but a compile-time resolved type syntax sugar.

"var xxx = 1.0" is exactly the same as "float xxx = 1.0", and works in C# too. It is still strictly typed, but leave the compiler the job of finding the proper type.

As example;

Code (csharp):

1. var xxx = 1.0;
2. xxx = new GameObject();

Would fail to compile, because the compiler found out that "xxx" is a float, and then you try to assign it a GameObject.

In typeless language, like Python, MaxScript and I think Ruby and Lua too, a variable may contain anything, and the above snippet would work just fine. In those language, there is usually no "compiler" that bytecode the script, it is interpreted - read - as the script is executed. It is far more flexible, but also have far worse performance.

JS (or US) in Unity is type-enforced just as much as C#. The real JavaScript can be typeless, but not the one used by Unity to build CLR library.