On Mon, 26 Mar 2018 14:30:38 +1300, Peter Reutemann wrote:
...and scripting via Python. ;-)
I had a quick look at the APIs for that. I was hoping for something DOMish, like you get with Blender. But while there is a bit of that, much of it seems to rely on directly exposing PyQT and expecting you to make calls into that layer.
"Why did you pick Python for scripting and not Lua (which is thread-safe)? Boudewijn: Because pretty much the entire VFX world uses Python, and because I wrote a book about Python in 2000 :-). And... Well... There is no safety in threads."
I posted a comment on the article about that. Quite a few people are keen to make Python (specifically, CPython) more “thread-friendly”. An inescapable part of this is getting rid of the infamous “Global Interpreter Lock” (which prevents multiple Python threads within a process from using CPU at the same time), which in turn means doing away with reference-counting and moving towards a pure garbage-collection model, like you get with Java. But that means also adopting Java’s requirement that you actively manage the heap allocation that you give to a program, rather than simply leaving the program to allocate as much (or as little) as it needs, as at present. Multithreading is something you avoid unless you absolutely have to use it. The main need for it is when your code is CPU-bound.