Accept paths as Path objects (not only strings)

[davidpagnon]

Brief summary of changes

Python pathlib paths are much cleaner and easier to use than strings, and it is the recommended Python approach for manipulating paths since Python 3.6 (introduced in Python 3.4). When using OpenSim in other libraries that work with Path objects, it is a bit of a pain and a source of errors to have to convert the path into a string.

The PR lets the OpenSim Python bindings accept paths both as strings and Path objects.

Testing I've completed

Please note that I spent a full day trying to build it from source without success (I'm definitely lacking practice for this), and I feel like I need to let it go for now.
I built it successfully now, but OpenSim still struggles to accept Path objects. Working on it now.

I'm fairly confident that it would work, but I did not test it. At the very least, someone should try to build it and test this:

import opensim as osim
from pathlib import Path
model = osim.Model("arm26.osim")
model = osim.Model(Path("arm26.osim"))

Fixes issue #4190

Looking for feedback on...

CHANGELOG.md (choose one)

Updated: https://github.com/opensim-org/opensim-core/blob/main/CHANGELOG.md

---

This change is 

[davidpagnon]

OpenSim is successfully builtnow, but it still struggles to accept Path objects. Working on it now.

[adamkewley]

I'm all for pathlib.Paths in python---I use them all the time in my own scripts, they're much nicer than strings when scripting---and I can help trigger builds etc., but I think one of the other devs is going to have to check if the approach being used is suitable for SWIG.

(I've never touched the bindings, so it'd be poor form for me to approve it, maybe @nickbianco / @aymanhab would know more about how/where type conversions should happen!)

[nickbianco]

Support for pathlib.Path would be nice addition for sure. As @adamkewley mentioned, SWIG is the main barrier here. The easiest solution would be to find a way in SWIG to convert the pathlib.Path to a string before passing it to the OpenSim object. But I'm not sure how much time and effort that will require, and whether simply doing osim.Model(str(Path("arm26.osim"))) is a suitable alternative.

[davidpagnon]

I tried to change the order of the items in the file (eg, putting %include "typemaps.i" and the Support for pathlib.Path objects block above %include "std_string.i", but regardless of the order, I've always got this error:

>>> from pathlib import Path
>>> import opensim as osim
>>> osim.Model(Path('Model_Pose2Sim_simple.osim'))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\opensim-workspace\opensim-core-build\Bindings\Python\Release\opensim\simulation.py", line 26802, in __init__
    _simulation.Model_swiginit(self, _simulation.new_Model(*args))
TypeError: Wrong number or type of arguments for overloaded function 'new_Model'.
  Possible C/C++ prototypes are:
    OpenSim::Model::Model()
    OpenSim::Model::Model(std::string const &)
    OpenSim::Model::Model(OpenSim::Model const &)

I must say that I'm not sure what to look for next.

[davidpagnon]

Doing osim.Model(str(Path("arm26.osim"))) already works, it is just a pain and a source of error.
I've seen many people in my team get tripped by it, and not understand that they simply need to reconvert the path to a string :)

[nickbianco]

I must say that I'm not sure what to look for next.

Do you know what C++ type SWIG is converting the pathlib.Path to internally?

[davidpagnon]

Honestly, it is the first time I deal with SWIG so I know very little about it. From what I can see, though, SWIG does not have a built-in typemap for pathlib.Path, hence the typemap that I proposed (and that gets ignored, apparently)