Python version of unified ev3dev API

[ddemidov]

This uses Boost.Python to wrap the existing C++ bindings into a python module. This approach has a couple of advantages:

1. No actual work is done in the wrapper code. The functionality is dispatched to the existing C++ code.
2. The wrapper code should work as long as the underlying C++ code is working.
3. The python bindings satisfy the unified API by necessity.

In order to use the python module, libboost-python-dev package should be installed both on the brickstrap machine and on the brick itself. In order to compile the module on the brickstrap machine, cmake should be installed there. The module may be compiled with the following commands:

cd ev3dev-lang/python/
mkdir build
cd build
cmake ..
make

The resulting ev3dev.so then may be copied to the ev3 brick and used from python (see demo examples).

[WasabiFan]

I'd love to have a Python binding in this repo. There are a few comments/questions that I have first:

• I'm interested in the idea of using the C++ binding as a base. Will doing this mean than any changes made to the C++ library will break the Python one?
• In this repo, we use an autogen script that we built to generate getters and setters for our bindings (see here). As we are transitioning over to this system, @fdetro has been working on the C++ transition over in this branch. That means:
  • Once we merge that branch back in to develop, you will probably need to adapt your binding to the updates.
  • You could make it much easier for yourself to maintain your binding if you use the autogen system as well (so that both can be updated in parallel as changes are made).
• Lastly, as discussed in #30, it would be even easier for you if you used your own repo to host your binding specifically and then we submodule-d it into this repo. That means that you can update your code as you wish without needing PRs and can have your binding kept with the rest of them. We have been using the naming convention ev3dev-lang-<language> for the repositories.

[ddemidov]

I'm interested in the idea of using the C++ binding as a base. Will doing this mean than any changes made to the C++ library will break the Python one?

If you are asking if the python module should be recompiled after changes are made to the C++ library, then yes, that is true. This could probably be somewhat relaxed by linking the python module to a dynamic C++ library instead of using ev3dev.cpp statically.

On the other hand, if some implementation details are changed inside the C++ library leaving the API intact, then no code change should be applied to the python module; a simple recompile would suffice. Of course, API changes would require some manual work, but I guess this is true for all languages in the repo.

In this repo, we use an autogen script that we built to generate getters and setters for our bindings (see here). As we are transitioning over to this system, @fdetro has been working on the C++ transition over in this branch. That means: Once we merge that branch back in to develop, you will probably need to adapt your binding to the updates. You could make it much easier for yourself to maintain your binding if you use the autogen system as well (so that both can be updated in parallel as changes are made).

I knew nothing about the autogen before today, but the idea seems reasonable enough. I think I should be able to switch to using the tool after the feature/autogen-cpp branch is merged. The autogen templates would be even simpler since I only need to enumerate the class methods without providing the actual implementation. Also, I see some inconsistencies of the C++ API are no longer there due to automation. That would make my task a bit easier :).

Also, as soon as you mentioned that these are actually properties, I realized that I should implement these as properties in python instead of blindly copying the C++ interface. I'll make the corresponding changes.

Lastly, as discussed in #30, it would be even easier for you if you used your own repo to host your binding specifically and then we submodule-d it into this repo. That means that you can update your code as you wish without needing PRs and can have your binding kept with the rest of them. We have been using the naming convention ev3dev-lang- for the repositories.

I think that's a good idea. One difficulty here is that since the python module I propose is based on the C++ bindings, I would probably have to submodule those inside of my own submodule (take that, Inception!). The C++ bindings are currently part of the main repo. Are you planning to split these into a submodule any time soon?

[WasabiFan]

On the other hand, if some implementation details are changed inside the C++ library leaving the API intact, then no code change should be applied to the python module; a simple recompile would suffice.

I think that the advantage of not having to update it for implementation changes should outweigh the downsides of the need for recompilation/modification.

The C++ bindings are currently part of the main repo. Are you planning to split these into a submodule any time soon?

That is up to @fdetro. I think that having the C++ binding split out would be advantageous for exactly this reason: it is the most likely for someone to want to use separately as a base for another program.

[ddemidov]

I've moved the python library to a separate repo. This PR now adds the repository as another submodule. I have also uploaded a binary egg to PyPI, so that it may be installed with

apt-get install libboost-python-dev
easy_install python-ev3dev