[Bf-committers] Python freeze progress... (long)

[Michel Selten]

Hi all,

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
  solution.
* 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
  incomplete.
  CURRENT_PYTHON_API seems to be the most complete for building a 2.2x
  api.
* When building with CURRENT_PYTHON_API, the module Blender is
  being created. This module has multiple references to parts of the
  intern/python component.
* At runtime the module _Blender is found by the various
  intern/python/modules/Blender/*.py files and thus the Python API
  works.
* Some people have reported about (N)Mesh not working, but we don't
  know any more particulars. Please file a bug at
  http://projects.blender.org/tracker/index.php?group_id=9&atid=125
* 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
  offend anybody.
* 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
  directory.

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
http://projects.blender.org/tracker/index.php?group_id=9&atid=125

With regards,
        Michel and LarstiQ