20,741
edits
Line 74: | Line 74: | ||
== Objective == | == Objective == | ||
{{FGCquote | |||
|1= For the idea of prototyping, you could set up a builtin Python package which provides a framework to create a new FlightGear subsystem. There's no point arguing if this is doable or not, because I know that anyone who knows Python, C, and the FG internals could probably embed Python, add read+write access to the property tree, and create this subsystem framework package in an extremely short timeframe (with real dedication, a week would not be unreasonable). I could probably do this myself in this timeframe, if it wasn't for my other projects ([http://forum.flightgear.org/viewtopic.php?f=47&t=28201 1], [https://sourceforge.net/p/flightgear/flightgear/merge-requests/30/ 2]). You can expose as much of the C++ internals as you wish with the Python-C API. | |||
Once you have a Python interface that allows for code prototyping, then this opens up the FlightGear internals to a much larger group of people. For example uni students, as a large number already use Python for prototyping ideas. Once the idea is tested, the code can then be ported to C++. Or if the performance impact is low, the Python subsystem can be integrated into the core without modification. | |||
Python is the perfect prototyping language for lower level languages, as it is one of the easiest to learn. Syntax-wise it is the simplest language. The prototyping potential of FG embedded Python is such an awesome feature, that it makes any arguments against it moot. | |||
|2= {{cite web | |||
| url = http://forum.flightgear.org/viewtopic.php?p=270799#p270799 | |||
| title = <nowiki>Re: FGPython an propose for Python as an nasal alternative</nowiki> | |||
| author = <nowiki>bugman</nowiki> | |||
| date = Dec 31st, 2015 | |||
| added = Dec 31st, 2015 | |||
| script_version = 0.23 | |||
}} | |||
}} | |||
== Motivation == | == Motivation == |