[Bf-python] Remote IPython & PyCrust Shell for Blender

[Stani]

Willian Padovani Germano schreef:
> Stani wrote:
> (...)
>   
>> In which Blender version could this be available? Threading for sure 
>> would help!
>>     
>
> Maybe 2.46, but threading was added to support pynodes and it's all 
> still experimental for now. As devs like you come with actual needs we 
> can try to improve things.
>   
Great!
>
> A quick test I did here with the default threading module in Python 
> crashed Blender (Python fatal error caused by the GIL (global 
> interpreter lock) being already taken, from what I recall, which the 
> module didn't expect). I searched online but threading is really a weak 
> area in Python, specially its documentation, and I could only find 
> someone with the same problem (*), but no replies with a solution. 
> Adding access to grab and release the GIL via BPython is a possible turn 
> around
OK, I would already be happy with any way to run a thread.
>
>   
>> One final note: it is really frustrating that it is impossible for 
>> scripts embedded in blender drawings (not the ones which are imported) 
>> that global variables don't work in the local scope.
>>     
>
> Let me see if I understood you. You mean gui callbacks have no access to 
> the global dictionary used by the script. That's true, the dict is freed 
> but the callbacks are left, it's not the fault of any script, 
I was referring to this mail, where console_autoexec.py was mentioned:
http://lists.blender.org/pipermail/bf-python/2007-October/005037.html
However when I look to the source of console_autoexec.py, it is empty. 
So what is the purpose of this file?
> it's how 
> it's always been in BPython. Thinking about it, it indeed seems better 
> to keep the dicts, too.
>   
What is the design decision behind it? When you import a module the 
global dict is kept and this problem doesn't occur. So I think it is 
very inconsistent and confusing if you are python developer interested 
in trying out Blender. I don't know what are the side effects of solving 
this, but I know that some python developers try Blender, but give up 
for such reasons.
> PS: just for fun I'm taking a better look at C sockets programming, 
> maybe it'd be nice for inter process communication via a scriptlink. 
> Don't count on it, though, I'm just researching a little.
>   
Socket programming in Python works fine. Being able to run a python 
socket server in a separate thread without blocking Blender UI would be 
already wonderful. So if possible I prefer first if thread(s) could be 
supported in some way, as it opens more possibilities than inter process 
communication.

Stani



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.blender.org/pipermail/bf-python/attachments/20080318/1e8478e4/attachment.html>