Python in FlightGear: Difference between revisions

Jump to navigation Jump to search
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 ==

Navigation menu