This has been discussed, on and off, for the past couple of years.
Some of the remaining key developers are indeed very much fond of Python.
Python isn't going to magically "solve" certain scripting related challenges we are seeing in FG (think Garbage Collection vs. Python's GIL).
However, Python obviously is great for a number of reasons, mainly excellent libs, tools, documentation, support and maintenance status.
That said, Python support is probably going to be added sooner or later - not so much in the form of a dedicated SGSubsystem, like FGNasalSys, but instead in the form of a HLA federate - HLA is going to make such things increasingly feasible, without introducing tons of bloat/dependencies.
Adding Python in the form of a SGSubsystem would be rather simple, but cause even more issues down the road.
However, even in a HLA-enabled build, adding support for more and more scripting solutions may cause interesting challenges, think "addons" requiring modules in Nasal, Python, Lua, Ruby, Perl etc - all of that will become a possibility, and it could be facilitated by the fgaddon/package manager (catalog) developments, because there will be much less oversight than there is currently when it comes to Nasal.
The way people are using Nasal is already hugely problematic and causing tons of challenges for the project, especially since the departure of mfranz, with nobody remaining to review contributions and ensure that modules are sufficiently generic in nature, and maintainable in the long term - right now, the situation with Nasal code is an increasing mess, and it is likely that this will not improve much by supporting even more scripting languages.
Technically, it is trivial to support something like Python - from a feasibility standpoint, there are other issues to be considered though.
I suggest you look at this wiki article, and links listed there:
http://wiki.flightgear.org/Nasal_success_storiesYou will find, that we've had a number of related discussions over the years, i.e. about providing additional scripting support and/or replacing Nasal in its entirety - e.g. see:
http://sourceforge.net/p/flightgear/mai ... sg21686158I would encourage you to look at postings from Melchior Franz, Andy Ross or other core developers with a track record of using/extending/maintaining Nasal (i.e. the core engine or even just fgdata modules).
In general, this is touching on the "plugins" discussion, too - because, ultimately, supporting more scripting languages will mean that people can use different technology stacks to accomplish their goals:
http://wiki.flightgear.org/FlightGear_PluginsWith Python you should keep in mind that Python comes with a huge community and tons of resources, including different package managers - FlightGear however is only just about to reinvent the package manager concept (from scratch):
http://wiki.flightgear.org/FlightGear_Package_ManagerIt would obviously be great to support Python, but most people seem to forget/ignore that this is causing tons of new challenges - imagine installing an aircraft via the package manager, that depends on a certain Python version, which in turn requires certain Python modules (think OpenCV, facetrack etc), with some of these being platform specific.
The FlightGear project is a hugely disorganized project and it is generally not very good at tackling such issues before they turn out to become real showstoppers - in other words, a few years from now, this (supporting even more technology stacks) will undoubtedly add to the workload of those shouldering much of the project currently.
If you are willing to "wait" for HLA to materialize, this will be the "more correct" path, but it still won't prevent people from implementing features (think aircraft) in a way that dependency bloat will sooner or later become a real issue.
When people say that they "prefer" language "X", what they're really saying is that they don't mind sytactic differences, but that they want to have more/better 3rd party modules.
If you were to provide a Python-based replacement next to FGNasalSys, the underlying FG related APIs would almost certainly (have to!) look the same, i.e. setprop/getprop etc.
And the next issue you would be facing is that people only care about certain features (think SGSubsystems), so that some stuff may end up not being supported by another scripting engine - imagine Python not having access to Canvas for instance (just intended as an example).
You do have a point regarding the "standalone" interpreter though - but even that can be accomplished using Nasal, in fact, there is a standalone Nasal interpreter that links to SimGear (headless) - something like that could easily be integrated with Stuart's HLA work to run /certain/ Nasal scripts as HLA federates (think AI tanker).
Supporting Python (or even Lua/JavaScript) could be great for the project (in theory) - but it is a step that needs to be carefully considered and discussed, and it would make sense to look at what people have previously stated in similar discussions, e.g. referring to:
http://sourceforge.net/p/flightgear/mai ... sg21686158Almost certainly, you don't just want to write your code in Python, but you also want to have access to certain/all FG APIs, and sooner or later people will also want to use certain Python packages, which may include binary packages (DSOs/DLLs).
But you should be also prepared to deal with these challenges, i.e. there is now an increasing trend towards online deployment of aircraft, I think we don't want to cripple such efforts by introducing dependencies to yet another scripting language and binary modules, possibly even platform/OS specific ones.
Such a step may affect/cripple FlightGear's multi-platform nature in fairly interesting ways - imagine addons like Bombable/Advanced Weather, Walker, Wildfire, Dual Control or FGCamera were implemented in other scripting languages, like Python, and what that could mean for the project from a workload/maintenance standpoint.
To be fair, there has been some discussion among a few core developers to entirely convert Nasal code in $FG_ROOT to Python code and replace the Nasal VM in its entirety - but many of these discussions don't make it to the devel list for understandable reasons