by Hooray » Sun Oct 09, 2016 4:50 pm
I don't think we are talking about the same thing - i.e. we are probably both right, but having different scenarios in mind.
Python support is indeed a huge technology-enabler, especially in conjunction with modules like PyOpenCL, which would open up a whole new world to FlightGear scripting, without any of it having to run in the main loop or a conventional CPU thread.
I am not saying that Python support is such a great thing (think GIL vs. Nasal), but a technology-enabler it definitely is, because once you have Python support, these things can be had "for free", whereas providing the same functionality in Nasal space would be a ton of work, which is what many users here were hinting at - then again, I do realize that you were asking about "Python the language" and not "Python the community/plethora of modules".
If I were as interested in this as bugman or Curt, I would look for compelling use-cases, e.g. the whole osm2city effort has tons of Python code that could benefit from having Python scripting built into FlightGear - likewise, a Python-based frontend like FFGo could be easily made to work without having to build a launcher from scratch (think the Qt5 effort).
Apart from the IPC bridge that Richard, James and Torsten talken about, there really isn't much missing to come up with a dedicated Python subsystem that asynchronously get/sets properties using an event queue and that can run fgcommands. At that point, you are all set and can do all sorts of fancy stuff without any of it having to clutter the main loop.
But again, when it comes to literally "replacing" Nasal it is worth keeping in mind that the OSG transition was initiated in mid 2006, and since then has never been fully completed, i.e. we still have tons of PLIB code all over the place, including code which is complicating matters for OSG tremendously - and it is particularly important to note that we're talking about native C++ code here - i.e. everything was/is completely under the control of our core developers, whereas that hardly applies to Nasal code (think aircraft scripts, scenery scripts, 3rd party hangars, addons like bombable etc).
In other words, literally ripping out Nasal to replace it by Python is going to be more challenging than refactoring a C++ code base, unless you are using a source-to-source transformation system to help with doing so.
I kinda like the "Superiority" short story you keep posting in these debates, because I can somewhat relate to it - however, it is also worth keeping in mind that with OSG, this whole technology-enabler thing ultimately turned out just right - i.e. shaders/effects, multiple windows/cameras, Rembrandt, ALS, earthview, Canvas etc - none of which would exist today (in its current form) had this not been committed back then.
And back in the early days of the PLIB/OSG transition that was a highly controversial thing, some of the most senior contributors were literally yelling at Curt for committing the patches in their form back then, and tons of debates took place on the devel list (and IRC!), given the plethora of regressions caused by that work.
Given that this debate is about Nasal, Andy Ross was particularly outspoken about the whole situation and not exactly happy with how things were handled back then, but 10+ years later, it seems everybody agreed that the transition to OSG (no matter how incomplete) was a smart move - but back then, Curt had to feel quite brave, and act boldly to actually do so ...