If it does become such an awesome addition, I would guess the core developers would shift it from optional to builtin.
That's funnily in line with James' comments on his Qt5 work being "strictly optional", despite him expecting it be shipped with all officials builds and used "by default".
Thorsten wrote in Thu Dec 31, 2015 3:38 pm:Basically I want FG to work out of the box once it's compiled, and talk about a huge collection of libraries to be utilized worries me.
I think that's a valid concern, and a point previously made by other contributors, i.e. see Melchior's comments quoted a few days ago.
HLA and Python support are definitely going to to be huge technology enablers, but there is the very real possibility for FlightGear to become increasingly "distributed" (as in "disparate") in areas where FlightGear the project may not yet be ready for it.
We started seeing that in the way increasing Nasal adoption has helped contributors use/develop FlightGear in areas that were neither foreseen, nor necessarily endorsed or even supported by core developers or the project as a whole.
Developments like the package manager/catalog system and the fgdata/fgaddon migration/split make it increasingly feasible to split up the project into entities over which "we" no longer have much control, including the possibility to see interesting, desirable, features developed in a "dead-end" fashion that isn't really likely to make it back into the project ever.
Personally, I don't have any doubts that Python support would be great, and that we would be in much better shape with Python support had it been added instead of Nasal, but these days, we simply have to live with certain facts, and porting/rewriting tons of legacy Nasal code is simply not feasible anytime soon (not even if done in an automated fashion using a Nasal to Python converted), which only leaves us with providing support for additional scripting languages, at which point the most likely thing to happen is that desirable features/functionality may only be available in language X, and never be made accessible in language Y.
We are already seeing tons of useful SG/FG APIs that are not exposed to Nasal space, and a future where aircraft/addons may end up using a handful of different scripting languages like Nasal, Python and Lua, there would be quite a bit of potential chaos coming out of all this. The only viable path to deal with that scenario is an IPC stack like CORBA or HLA/RTI that can deal with these challenges.
Compared to Python or Lua, Nasal sucks for a a number of reasons - but let's not underestimate the degree of stability and longevity Nasal provides for the same reasons that make it not very compelling for people wanting to use Python or Lua.
I don't think that it would take a whole week to prototype Python support in the form of a dedicated SGSubsystem that runs inside the main loop, I could probably come up with such code in a single weekend of spare time hacking, making the property tree and other APIs functional is obviously taking more time - but apart from that, the steps are straightforward actually, the links I posted should be able to get people going quickly, i.e. those seriously interested in Python support.
In all fairness, I am not prioritizing anything related to this myself, but a number of core developers have previously expressed a strong desire to add Python support, i.e. beyond Curt's encouragement, there are people who really would like to provide a Python alternative, and potentially even a replacement.
I don't agree with all the reasons behind that thinking, but I am willing to help people come up with the boilerplate/integration code to end up with a Python interpreter running within the main loop, it's not rocket science after all - and having options is generally a good thing for the project. Over time, this may at least have the benefit that scripting in FG stops being the chaotic mess that it has become over time.