[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
api.
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
source/blender/bpython/
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
all!
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,
Michel