[Bf-committers] Languages other then python in Blender 2.5?

Ton Roosendaal ton at blender.org
Fri Feb 13 10:40:45 CET 2009


Hi,

The current status of 2.5 (RNA and Operator level) will allow other 
scripting languages and even C plugins. However, that's only one part 
of scripting requirements. There's also need for integration with the 
UI - or configuring the UI entirely - event handling, render 
export/integrations, node systems, and not to forget requirements for 
our animation system (drivers, constraints, scriptlinks, etc).

So, there's a lot of design decisions we have to make... and I'm not 
very fond of limiting - and complexifying - design by adding a 
requirement that any scripting language should be plugin-able. I 
seriously doubt we have the the development powers for this even.
Let's first try to solve all requirements in the most optimal 
end-user-friendly way with Python, there's sufficient people here who 
know other languages who can point us on the 'point of no return' 
decisions that effectively will rule out any future other scripting 
language.

-Ton-

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

On 13 Feb, 2009, at 4:17, Campbell Barton wrote:

> Much of blenders 2.5's scripting will boil down to RNA access or
> calling operators, making it easy to add access to new languages.
>
> The 2.4x py api was such a monstrosity nobody wanted to do this for
> another language but Id guess a 2.5 api for lua could be done in
> 1000-2000 lines,
> with RNA and Operator changes automatically accessible from the thin
> API (just like the py api).
>
> IMHO it's quite likely that with Blender's popularity some developer
> will try this even if we don't ask for it.
>
> If someone adds access to another scripting language (say Lua, Ruby,
> ECMA-Script) and will maintains its-
>  Would this be acceptable to include with Blender?
>
> I ask this because it influences how the new Python API accesses
> blender functionality. If other languages are likely to be added
> later, its more important to keep the current python api access
> generic without hand written C/Python functions.
>
> Some arguments for and against this...
>
> Pros - (probably missed some since i don't use other scripting 
> languages)
> * Makes developers of "insert-fav-language" happy/productive
> * Allows switching to Mono, Lua, Ruby or whatever - if for some reason
> we want to???
> * keeps the api generic so we dont slip into adding evil hacks for one 
> language.
> * Some languages are better then python for certain tasks.
>
> Cons
> * May end up with many half supported languages, rather then 1 well
> supported language.
> * Complicates building/installing blender (bloat)
> * May complicate changes to the C rna and operator api breaking one
> language but not another.
> * Fragments scripting community
> * * maintainers need to know more languages
> * * makes it harder to read/review scripts in blender that were
> written in different languages
> * * documentation for new users will vary from between languages.
>
> Id like to be clear on weather this is a possibility for 2.5 or not.
>
> *Note* Ignoring the BGE PyAPI here, that will not be changed much in
> 2.5 since python is built into the C++ classes.
>
> -- 
> - Campbell
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



More information about the Bf-committers mailing list