Python3 embeded python terminal

[MaximilienNaveau]

I found a weird bug using the python3 embeded terminal and the dg_completer.
The interpreter get stuck upon import readline or from rlcompleter import Completer.

It is a shame as the completion is a huge bonus in the client terminal.
This Issue is also in reference to the dynamic-graph-bridge python client of course.

Let me know if there is something I am missing.

Are you using the dynamic-graph-bridge already with python3?
If yes how do you do? (Maybe this question is for dynamic-graph-bridge)
I personnaly did a small C++ client using the ros-service and bound it pybind11.
So I can use ROS in python2 and 3 seemlessly.

[MaximilienNaveau]

I just wanted to mention the corresponding dynamic-graph-brigde issue related this.

[olivier-stasse]

Dear Maximilien,
I implemented the rlcompleter but my impression that having the ipython kernel working would be simpler for us.
But the ipython kernel is supported only by python3.
I am not up to date on this, so I let other people answer on this (maybe @nim65s who knows python3 more than me).
So I would be very happy to test your client, but I do think that when switching to python3 ipython might be come with interesting features which might be worth investigating.

[MaximilienNaveau]

I was wondering if we could use the pybind11 embeded python terminal as well. I am not sure which one is the best...
I will investigate the possibility of the ipython terminal. Anyway if everything goes well in python3 I will definitely cut-off python2 on my part. And move on to ubuntu18.04/python3 for good.

[olivier-stasse]

@MaximilienNaveau I do not know pybind11. If you can make a comparison between the solutions, we are open to any solution which can improve the current status. Please be aware that there is an effort in switching to boost::python currently ported by @jmirabel

[nim65s]

pybind11 is just a modern boost::python without boost. There is no change in using one or the other, except:

• if you already have boost, you already have boost::python, so don't go for an additional dependency
• if you require C++ < 11, you can't use the modern pybind11.
• otherwise, pybind11 is a lighter dependency than boost.

But the API and functionnalities are the same.

[jmirabel]

But the API and functionnalities are the same.

Although very similar, the two are still not the same in terms of API and ease of use. pybind11 is definitely a lot easier to use not only because C++ 11 itself but because the API and function names are clearer than that of Boost Python. If you can choose, go for pybind11.

The only unclear part for me is the link between Eigen and NumPy. pybind11 provides a basic support for Eigen. I don't think it is as complete as eigenpy but I am not sure of this.

[MaximilienNaveau]

For pybind11 the eigen support is not too bad but induce a necessary copy of the data. Which might have been prevented in eigenpy (I do not know about this.).

Thanks for all the inputs. I would like to be on the same page as you guys for the python bindings as it make the code compatible through both institute. Clearly the current bindings and pybind11 are not compatible (I tried too pass a pinocchio.SE3 object to a C++ function binded with pybind11 and failed). We are currently heavy users of pybind11 though, so I will see if switching to boost::python is not too constraining...

So if you guys say that you go for boost::python I should look into it and maybe provide tutorial for my team.
Then again I think we should merge our control infrastructure as well at some point. I am working on some improvement on mine to ease this process.

[jmirabel]

Clearly the current bindings and pybind11 are not compatible (I tried too pass a pinocchio.SE3 object to a C++ function binded with pybind11 and failed).

It's not out of the box but it is doable.

[MaximilienNaveau]

If you have a guide on how-to I am interested!

[jmirabel]

No link. I came to that by trial and errors.

https://github.com/hungpham2511/toppra/blob/6e903f435d6a583aad731e67a4224fea7c830b27/cpp/bindings/constraints.cpp#L106 allows you to extract inside pybind11 an object exposed with boost python.

There is probably an automatic way of doing it by registration of a cast. It's a bit tricky because you have to go into the internals of boost python or pybind11. I haven't tried.

[MaximilienNaveau]

Ok that a very good help! I will probably try to do that and if the compatibility is doable and not too annoying then I will keep pybind11 as our main python bindings.