[Bf-python] Memory bug in Bpy api

[Bobby Parker]

Can you suggest a better method of developing a script in such a fashion
that several people can work on components of it? The primary issue with
this script is that the GUI code is so large (almost 600 lines for the draw
function, for just the shader editor alone) that it becomes cumbersome to
work on with just one draw() function, and I do expect it the other modules
of the script to have needs as demanding. My initial thought was that I
could register a "master" draw function to handle routing to various modules
based on the value of a 'state' variable, and while that does seem to work,
it also introduces these memory issues. The modules I'm developing here are
less a means of "reusing" code than it is to provide some ease of modifying
components of the script as a whole.


Also, I'm not following your above indicated method, rather I'm doing import
from math.* since the Register() function doesn't appear to be happy with
callbacks stored in a module (as in ShaderEditorGUI.draw()), since that
loads the functions/variables I need into the current namespaces( at least I
think/hope that's what's happening, and results seem to bear me out).

I'm going to try a few things (like accessing the blender.draw() using the
<module>.<attribute> style) and see if that changes thing memory wise.

Many thanks

Bobby Parker

On 1/18/06, Willian Padovani Germano <wgermano at superig.com.br> wrote:
>
> Hi,
>
> One thing has nothing to do with the other:
>
> Global dicts:
>
> Each script in Blender has its own global dictionary, that gets deleted
> when the script finishes executing (GUI scripts and also those who call
> the file selector leave callbacks, so we postpone removing their global
> dicts until they are really finished). This keeps things clean, with one
> script not affected by another's namespace.
>
> Note: among other changes, after 2.41 I plan to keep the global dicts of
> script links (including space handlers) around, to make writing these
> scripts easier and running them faster. Each will still have its own
> global dict (that gets cleaned (deleted) when an error occurs), so no
> namespace issues still.
>
> Modules:
>
> Python modules are not reloaded unless you specifically tell the
> interpreter to do so.
>
> To solve the problem of vars created in modules being persistent, simply
> *do not use modules to store new data* -- do not do this:
>
> import math
> math.myvar = <something>
> math.myfunction = f
> #etc
>
> Use the Registry dict, use a Blender text, save data as a file (the
> Registry can do this for you). Storing vars in default modules like
> math, etc. is like adding new vars or functions to a system library.
>
> Besides not being a clean way to code, it also pollutes the modules that
> other scripts will use. Imagine if many authors start doing this, soon
> one script will change the data created by another and cause trouble.
>
> Saving GUI buttons in modules would be even more troublesome, these
> don't stay around for that long, Blender recreates buttons on every
> redraw. That's why they should be created in the draw callback that you
> register with Draw.Register.
>
> --
> Willian
> _______________________________________________
> Bf-python mailing list
> Bf-python at projects.blender.org
> http://projects.blender.org/mailman/listinfo/bf-python
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.blender.org/pipermail/bf-python/attachments/20060118/f389c83b/attachment.html>