[Bf-python] External scripts

[Stephen Swaney]

"Gilbert, Joseph" wrote:
> 

> Does this mean it would be integrated or would the full distro of python
> have to be installed still?

I think you could do most of it with the standard language, a math
library and an opengl lib.  No doubt, other bits like networking
would be useful for clever stuff like distributed rendering.  But
that is just icing on the cake.  All very easy to import as needed.

Without going into a lot of detail, the way I see this working
is that tasks like adding an object, rendering a scene or saving
a .blend become python commands in an extended interpreter.  The
goal is to make any blender action directly scriptable.  The GUI
simply makes calls into these routines.

The implementation of these commands is in C or C++. 
For this, we can scavenge and reuse large amounts of existing 
blender code.  This is also why using an interpreter as a
framework is not a performance bottleneck, a question that
comes to mind immediately when people hear about a python-based
blender.

Internal data structures, like the various lists that appear
everywhere in blender, would be implemented as native python
data structures.  Python provides a nice api for accessing
its various lists, tuples, dictionaries, etc.

It may be useful to drag along something like PyNumeric, NumPy or 
whatever it is calling itself these days.  This is a python extension
for doing fast math on large sets of numbers.

> Also have you looked at stackless python? I was wondering if this would
> be useful for the gameengine or verse. Don't know really. Just some
> ideas.

I looked at stackless python a long time ago.  It seemed useful
for problems like simulations that would naturally partition 
themselves into hundreds of threads if it were not for the
overhead of context switching.  Might be nice for actors and
agents in a game engine.  Probably not much use in blender core.
( /me indulges in momentary insane fantasy where each pixel is
an agent running in its own thread.  ok, that's done. )

-- 
Stephen Swaney			
sswaney at swbell.net