[Bf-committers] Python freeze progress... (long)
01 Feb 2003 21:42:55 +0100
Currently a lot of questions concerning the Python api in Blender have
arisen. In this mail we hope to clear some things up.
* LarstiQ and I have been busy trying to understand the internal
mechanism of Blender with regard to Python.
* We're focussing on getting the API to a point it is at the same level
as of Blender 2.23.
* No effort is being put in getting the game engine API to work.
* When tinderbox was up (beginning of januari I believe), the build
seemed to fail on intern/python/freeze. The log contained multiple
ImportError lines. I made an update to cvs which removed all
references to modules that the freeze could not find. This resulted in
0 build errors and most platforms going green on Tinderbox.
* The update in cvs also had some effect on the python api. To revert to
previous versions of the files at this moment seems not to be a good
* In source/blender/bpython/intern it is possible to build an
implementation of the api using FUTURE_PYTHON_API. As far as we can
tell, this is an implementation which was being developed at the end
of the NaN period. According to the README this implementation is
CURRENT_PYTHON_API seems to be the most complete for building a 2.2x
* When building with CURRENT_PYTHON_API, the module Blender is
being created. This module has multiple references to parts of the
* At runtime the module _Blender is found by the various
intern/python/modules/Blender/*.py files and thus the Python API
* Some people have reported about (N)Mesh not working, but we don't
know any more particulars. Please file a bug at
* in source/blender/bpython/intern there is a file api.h
Through many #define statements the module name is generated. It's a
heavy #define file.
There are some preprocessor tricks that are used for defining the
name. (Example is the double hash (##) in init##x).
In our humble opinion this is ugly code. Ofcourse we don't want to
* The philosophy of the blender directory tree is that the sources in
intern do not depend on anything in the source directory. That means
we can't create some process to actually look in the source directory
for existance of a module named _Blender.
The sources in source can ofcourse refer to any file in the intern
What are our thoughts on what should be done:
* document the build process on the Python part with regards to
intern/python/freeze and source/blender/bpython.
* Investigate the current status of VRML import. I made an update to
remove an ImportError message as well in that code, but we don't
know what is working. Please test.
* Somehow create a sollution so that the freeze process 'knows' which
modules it should not complain about. Then no 'ImportError' messages
are shown and Blender has a Python api - including VRML import.
* When the python thing is working for blender, with all the hacks
currently made, we want to spend some more time on how freeze works
and if we need it. This is clearly something for after 2.26 :) There
are no idea's yet on how to do this; our energy is currently being
spend at getting Python working for 2.26.
Currently we have the following questions:
* Where do we find the blender 2.10 api in the blender source tree?
* What are the differences between 2.23 and 2.25 from an end-user point
of view? What are known problems in 2.25?
As I've said at the beginning of the mail, we're currently focussing on
repairing the api. Any feature request, or even redesign will have to
wait after the api is 2.23 compatible. We hope you understand.
Any questions/remarks to the current process and effort to get Python
working on Blender are ofcourse appreciated.
Please file bugs at
Michel and LarstiQ