[Bf-committers] Bundle Python 3.0 for Blender 2.5

[Ton Roosendaal]

Hi,

I think it's very important to stick to the smallest feasible 
targets... thanks to work we do on fixing event/tools, we will have RNA 
(data API) and Operators (tools API). These apis can be automatically 
wrapped to python, or any language even.

However, there it stops for me. We wills still have a lot of calls in 
Blender that are very useful for Blender as-a-tool, but not "a correct 
API" or automatically wrapped. For that a more manual Python api is 
still the best and quickest solution, think here of things like UI 
stuff, managing certain data operations, etc.

Further, in my view Blender is not an Application Protocol Interface, 
it's an artists' tool. The formentioned improvements (RNA, Operators) 
are based on improving useful end-user specs. Let's try to get that 
realized first. :)

About the bundling: I'm all in for a binary without external 
dependencies, something that installs with installation procedures. 
Python scripts are based on enabling useful end-user features, and can 
therefore be easily bound to a specific release of Python... provided 
that release is stable, and expected to stay there for many years. We 
can even stick to python 2.5, for that reason.

Of course I'm talking about releases we do, and the standard scripts. 
Next to that (we can even release that too) versions that allow custom 
python installs are well possible.

-Ton-

------------------------------------------------------------------------
Ton Roosendaal  Blender Foundation   ton at blender.org    www.blender.org
Blender Institute BV  Entrepotdok 57A  1018AD Amsterdam The Netherlands

On 5 Dec, 2008, at 19:10, joe wrote:

> I second the part about the C API.  We need to be careful we don't 
> lock our API code into python.
>
> Joe
>
> On Fri, Dec 5, 2008 at 9:25 AM, Chris Want <cwant at ualberta.ca> wrote:
>>
>>  Reading this thread, I become more agreeable to the suggestion
>>  that Early Ehlinger made earlier (no pun intended). He suggested
>>  that python scripting should be handled as an external plugin
>>  that loads at run time. Then the problem of having builds of
>>  blender for different python versions doesn't matter: just
>>  have one blender build and distribute it with plugins for
>>  the different python versions. This, of course, would be a
>>  lot easier with a well thought out C API, which I believe should
>>  be the first step before tackling python (as I've mentioned
>>  before).
>>
>>  I should also point out that bundling python with blender adds
>>  extra complexity to Blender's plethora of build systems. The
>>  example of FFMPEG is a poor one since not all build
>>  systems support it, there are issues under windowa, the
>>  scons system supports it by having the additional
>>  requirement of having autoconf installed, and I have
>>  recently seen mails on the list from our game engine developer
>>  trying to change the FFMPEG sources in extern, to which
>>  there are no replies from the official maintainer. This is
>>  not a role model to follow.
>>
>>  Cheers,
>> Chris
>> _______________________________________________
>>  Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers