[Bf-committers] tackling Python (long)

Michel Selten bf-committers@blender.org
14 Feb 2003 20:50:06 +0100

Hi everybody,

(instead of contacting only the ones who showed interest in working on
 Python, I opted for mailing this to the list because this mail contains
 more political than technical issues).

I've had some time to think about how to tackle the python part in
Blender. Some of the issues I've written down below, are just my
thoughts, others just guesses and some may be even plain stupid :) But
hey, I think writing such mails will get things started.

* Blender 2.10 api
  Do we want the 210 api back in Blender? A simple answer may be 'yes',
  but do we want it back at all costs? It could be that we can get the
  sources, but we are not sure how easy it will be to integrate them in
  the current tree. If we have to write it from the bottom up again, do
  we have the api spec?
  Personally I think that if we are able to have the sources and it's
  fairly easy to integrate them into the tree, then we should do it.
  Otherwise we should focus on improving the current api.

* vrml
  How about removing the vrml import sources from the tree and convert
  the sources to a plugin? I don't know -yet- if the current api
  supports enough functionality to do so.
  If we can do this, then the vrml import plugin can be maintained
  independently from blender, just as the YAFRAY export plugin.
  (hmm, maybe I should replace the word 'plugin' by 'python script').

* freeze
  Remove freeze. Although the action itself will probably be very easy,
  a replacement needs to be implemented which will take more time :)
  From what I've seen so far, it should be possible to create a Python
  api for Blender from C. The next 4 points describe in more detail how 
  I think this could be done.

1-Update the auto* environment
  This entails adding a '--enable-experimental-python' option to the 
  auto* build. Ofcourse we can alway discuss the name for the option :)
  Using the option, freeze will be built or not. If not set, freeze will
  be built just as it is now.
  In the source tree all calls to source/blender/bpython functions need
  to be #ifdef-ed to make the calls only if the option is not set. In an
  #else section, calls need to be made to the new api.
  Also, use the option to either build the source/blender/bpython part 
  or not.
  When this is done, it should be able to build and run blender with the
  '--enable-experimental-python' option set, but python shall not be 
  linked against blender and ofcourse python will not work :)
  (There probably need to be some more updates to actually link without
  errors, but I didn't investigate this in so much detail).

2-Leave the source/blender/bpython directory as is
  For now, don't touch these files. If compiled without the 
  aforementioned option, we still want to be able to build the current 

3-Create a new directory source/blender/python/2.2x (yes that is python
  without the b prepended)
  Within the 2.2x api, we will implement a new api which is fully
  backward compatible to the current api, but entirely written in C. We
  can probably copy a lot of code from source/blender/bpython.
  Why didn't I choose not to implement a new api within the bpython dir?
  Well, the current state in that directory is that a _lot_ of #define
  statements are used in there, and to be honest, I don't dare to touch
  many of them :) Things will probably get even more broken.
  This step will take some time to complete, but it shouldn't hinder any
  blender releases. Until we are confident it works, build without the
  new auto* option.

4-Remove all the old python api stuff from blender.
  Well, ofcourse we want to keep the sources somewhere, but move them
  out of the main tree. This includes intern/python/ and
  Also remove the --enable-expiremental-python flag from the auto*
  environment and update all related source files.
  Make a new blender release :)

* Meanwhile, think about new api
  In the meantime we could investigate the shortcomings of the current
  api and design a new one. This could mean that we create an entirely
  new api with new blender-python modules. We could even use another
  convention for naming functions, modules and constants. I leave that
  open. It's still fuzy for me, but I think that's good for keeping an
  open mind :)

* Implement the new api
  I'm thinking really future here (somewhere around the year 2025). Well
  I hope sometime sooner, or if we don't want a new api, then not at 
  One thing that I find very important is that whatever we implement now
  in Python, should be available - and work - in the future.
  We could follow the same strategy as was done with the 210 api:
  '#import blender22x as blender'.
  Ofcourse a small update needs to be made to one or two files in
  source/blender/python/2.2x to accomplish this

Well, enough for now. This mail is getting too long already, but in my
opinion it's an important thing to exchange some thoughts on.

Please tell, me what you think.

With regards,