Determine Python Architecture about xplaneconnect HOT 5 CLOSED

I have written an initial draft of a Python version of the interface, which can be found here. My primary goal in writing this was to force myself to give the C code a deep, thorough read through. Since it's already accomplished that goal, any additional usefulness it has is a bonus in my mind. (In other words, I won't be the least bit offended if no part of this branch is ever merged.)

I initially thought it might be a good idea to python's extension module system to leverage the existing C code. However, after a little research I believe that this approach would significantly increase the burden on the end user. It would also probably require significant modification of the C code anyway.

After abandoning the extension module idea, my basic goal was to port the C code base into pure Python, while maintain as much conceptual commonality as possible. To that end, the code linked above follows basically the same structure as the C version with the following notable changes:

• Object orientation
  • All functionality is exposed via the XPlaneConnect class
  • The class maintains socket state internally, so that it is not necessary to pass socket info into every function as an argument
• Naming
  • I have changed most names to snake_case to match Python's style guide.
• Parameter passing and return values
  • Fundamental differences in memory management between C and Python necessitates significant changes to the way data is passed between functions.
  • Instead of passing one or more pointers into each function to store results, the results are returned directly.
  • Where necessary, Python's strong support for multiple return values is leveraged to return multiple pieces of data.
  • It is not necessary to manually track the length of collections in Python. As such, many arguments and return values that are necessary in C simply disappear in the Python version.
• Error handling
  • Errors are handled by raising exceptions instead of return codes
  • Exception based error handling and the elision of length variables mean that most methods still only need to return a single value.

I am currently in the process of porting the existing C tests, however it looks to me like most of them run against an active instance of the plugin running in X-Plane. I haven't purchased X-Plane yet, so I can't run most of the tests myself.

Hopefully this is a good jumping off point for discussing what the Python architecture should look like. Any and all criticism, comments, questions, etc welcome.

from xplaneconnect.

Hi Jason,
great piece of work. I have been trying to get a python interface towards x-plane 10 (steam edition on ubuntu 14.04 64 bits) and stumbled over de nasa plugin.
I use pycharm for my (professional) python work and found a few issues in the code which I would like to share with you. Mostly pep-8 related but also some parameters which are not used or of the wrong type.
My goal is to write a moving map application using QT5 as a gui.
Largest issues I found:
def read_pos(self, result_array, gear): # TODO parameters are not used
def read_ctrol(self, result_array, gear): # TODO parameters are superfluous
in parse_dref: len_val = struct.unpack_from("B", msg, 6 + len_dref) # TODO solve type error in len_dref
in send_dref: msg_len is not used
in parse_getd: len_list in the range function is not of the correct type
def read_request(self, recv_addr): # TODO parameter recv_addr not used

When I can help, please let me know how I can share in the effort. I use Python 3.4 since that is better for working with QT5

greetings

from xplaneconnect.

Hi Robert.

Thanks for your feedback. As you can see from the commit history, it has been quite some time since I touched the Python client. At the time I wrote it, I had very little experience with both X-Plane and X-Plane Connect. I've been working on X-Plane Connect full time for the last month, so I have a much better idea now of how the Python client should work.

We are currently working on internal code review for the 1.0 release, so it may be a few days before I can get back to this. It happens that cleaning up the Python client and getting it ready for release is next on my to-do list after we finalize the 1.0 release, so I'll take a look at the issues you noted as soon as I can next week.

from xplaneconnect.

Hey @RobertLos,

Sorry it took me all week to get back to this. I've fixed up all of the issues with the client that I could find, and added tests to cover our common use cases.

Unfortunately we need to support Python 2.x, so that's what I'm targeting right now. I'm not opposed to adding support for 3.x, but I would really like to find a way to do that without having to maintain two completely separate modules. I don't do a lot of work in Python, so I don't know whether there are common ways to accomplish this that are used in the Python community. Do you have any ideas?

from xplaneconnect.

Hi Jason,

Sorry from myside also to reply this late. Have been on a holiday to Paris.
The syntax differences between python 2 and 3 are not too dramatic. You
can coe in python3 style (parenthesis around strings in print
statements, etc) and python 2 will still accept that. You can
Why do you need python 2.x? The only reason I can think of is that you
are using some library that needs 2.x. Look at
https://wiki.python.org/moin/Python2orPython3 for a discussion.

For my work I have setup a jenkins based continuous integration
environment for python development (well actually jython wlst for oracle
weblogic deployment). It gives good feedback on code quality and style.
If youm like we can try to setup a ci enviironment that does some
monitoring on the development.

greetings

Robert

Robert Los Commercial & Contract Services
Nachtegaallaan 46
3055 CS Rotterdam
The Netherlands
T: +31 10 2857015
M:+31 6 24893872
E: [email protected] mailto:[email protected]
www.robertlos.nl http://www.robertlos.nl

On 01-05-15 22:58, Jason Watkins wrote:

Hey @RobertLos https://github.com/RobertLos,

Sorry it took me all week to get back to this. I've fixed up all of
the issues with the client that I could find, and added tests to cover
our common use cases.

Unfortunately we need to support Python 2.x, so that's what I'm
targeting right now. I'm not opposed to adding support for 3.x, but I
would really like to find a way to do that without having to maintain
two completely separate modules. I don't do a lot of work in Python,
so I don't know whether there are common ways to accomplish this that
are used in the Python community. Do you have any ideas?

—
Reply to this email directly or view it on GitHub
#8 (comment).

from xplaneconnect.