Quote:There's two questions I'm unsure of: whether it's better to aim for embedding Python within the library or extending Python with the library; and if extending, whether to plan for using C++ or C for the code.
I'm going to say extending is better.
Firstly, Python simply is not designed to be embedded. There's no getting around that - the API has lots of global state, subinterpreter support is barely existent and not maintained, you typically have to recompile the Python DLL to match your current runtime (including building a debug DLL), etc.
Secondly, it goes against normal software wisdom to write the main part of your app in the lower level language and then to add a higher level language on top. <speculative>These bolt-on solutions probably originated in things like Excel where the need for user-defined formulae grew into scripts, and have crossed over to become prevalent in game development thinking because we are unable to give up the C++ legacy for various reasons.</speculative> Yet developers without such legacy code to worry about will almost always prefer to code in the most expressive, most high level language available, and then drop down to lower levels to optimise, if and when needed.
Quote:If extending, I'm also not sure whether it would be best to use C or C++ as my language of choice for the library functions.
It's not really an issue. If you use a helper library to extend Python, it'll sort that out for you. If you don't, you'll be binding C functions through necessity. (Probably wrappers for your C++ functions.) Or just build them as .dlls and load them via ctypes.
Quote:Quote:There are downsides to this. In addition to the points in the article you mentioned, multiple threads and embedded Python do not mix well.
Me too; my apps haven't been advanced enough for me to worry about multi-threading. Consider everything I plan to do to be single-threaded for now.
Yet Python offers ways to make the move to multi-threading quite easy, eg. the queue module. That's one of the many benefits of working in Python.
Quote:Quote:Also, the Python community isn't very friendly to people who embed rather than extend, so getting help from them can be an exercise in frustration if you embed.
That sucks; is there a strain of elitism in the Python community?
It's a community of Python users, who presumably like using Python and consider it the best tool for many tasks. If you go in there asking them how to use the language in a way it wasn't designed for, and as essentially subservient to a language that (a) they are less qualified to help with, and (b) is probably worse for many of the tasks you'll put it to, then they're less likely to be able to offer you anything positive. They will probably be a bit frustrated because if you chose to use it the 'proper' way, they could provide more help.