Integrating Python further into Blender
Brief summary of your proposal (max. 200 words):
The purpose of this paper studying the ways Python is becoming integrated into Blender, and finding strategies to do it well in the future.
Blender embeds Python. The interpreter is included in the application, which provides an API for scripting. This has been succesfull. People are breaking the limit of what Python can do in Blender (OOPS, GUIs?).
There are problems: much of the functionality that is available for C is missing for Python. New features are added to the core, and then again someone needs to add new hooks the the Python API. Could and should something be done about this?
An extreme solution would be re-architecturing Blender to extend Python. It would be libraries, which would be Python modules. The ways of restructuring the core are also independent of this Python issue, but if it is done, it could greatly facilitate this. If necessary for e.g. performance reasons, the mainloop could still be the current C implementation. If PythonBlender existed, Blender could be used by other applications as well. But this approach is obviously very problematic and may be practically impossible.
This paper contributes to the roadmap about Python and Blender, and to the modularization of Blender.
Extended version:
The purpose of this paper is to study the ways Python is becoming more and more integrated into Blender, and find strategies to do it well in the future.
Currently, Blender embeds Python. This means that the interpreter is included in the application, which provides an API that can be used for scripting within the application itself. This has been quite succesfull, as the growing number of useful scripts demonstrate. The API is expanding continuously, and people are experimenting with new kinds of functionality made in Python. Interesting recent examples of this include enchancing the OOPS window by Campbell Barton and using the Draw module for creating customizable GUIs? through the Python API.
However, there are problems and limitations too: there are several things that can't be done via Python, and (potential) developers are continuously facing the problem that functionality that is available and defined in the components written in C are is available from Python. Sometimes it is almost like a race: new features are added to the core, someone wants to use them from Python but can't, and then again someone needs to add new hooks the the Python API. Could and should something be done about this? Or is the current mode of development ok for the future too?
An extreme solution in the long run would be to change the whole architecture so that, instead of embedding, Blender would extend Python. This would mean that all of Blender would be refactored as libraries, which would also be made Python modules. This way Blender could be a Python package (basically just a directory), that includes the parts i.e. (sub)libraries as modules. The ways of restructuring the core are also independent of this Python issue, and beyond my areas of expertise. But if such restructuring and packaging is done for other reasons, it would facilitate making the libraries Python modules too. For example, if the user interface would be a separate component that just used the core, the core would have to provide the means to make the UI. Then, that functionality could be exposed to Python , and it could be used to fully program the GUI (although as the actual UI library is implemented in C, it is not quite as simple as that). Then making Blender to extend, instead of embed, Python would mean that the main application would be made a Python program. In a simplest form, it could be something like: import Blender; blender=Blender.Application(); blender.main() . That is, if necessary for e.g. performance reasons, the mainloop could still be the current C implementation. But if the functionality it uses is provided to Python, people could relatively easily make their own different applications too. Furthermore, if such refactoring can be done, parts of Blender could be outside of it in other applications as well (I'm personally curious about the IPO module). But this approach is obviously very problematic and may be practically impossible.
Much has been already said about the modularization of Blender, and there are clear needs for that. One example is the work of Alexander Ewing (intrr) on Instinctive Blender, which is a fork of the official Blender that originated from the need of a different GUI. This paper tries to build on the other works on modularization from a Pythonic perspective.
-
http://www.kyperjokki.fi/tools/blender.py is a (so-far) fictional example of how Blender that extended Python could be used.
This proposal is partly based on the draft document I've been slowly putting together in http://studio.kyperjokki.fi/engine/PythonBlender , where are links to references, current developments etc.
For an essay which discusses embedding vs. extending Python approaches and argues strongly for extending, see http://twistedmatrix.com/users/glyph/rant/extendit.html