利用者:BayesianHorse/BlenderPythonWishList

A Pythonista's Wishlist for 2.8

I am not a Blender developer, so I know I can't implement these wishes or expect anyone else to fulfill them. I do believe however, that this list may be interesting to some in the community.

TL;DR:

• native, official AsyncIO integration
• support for Cython
• generic Python callbacks for operator calls
• replace the blender-specific Python distribution with Continuum Analytic's Conda
• numpy array access to audio samples
• more Numpy in general

Native, official AsyncIO integration

AsyncIO is already in the Python standard library and is quickly becoming the standard concurrency framework for Python. In case you don't know what concurrency is: It's not threading, and Blender already operates this way: work is split into fragments of codes, which are bound together by callbacks waiting for events like IO or user interaction.

I already wrote a basic integration of asyncio for Blender, and it enables non-blocking network programming, a more convenient syntax for user interaction in scripts and generator-driven macros. Among other things, it allows for http servers running inside blender and better communication with external processes.

The current state can be seen here: https://github.com/akloster/blender-asyncio/tree/wip

However, this is not very easy to get working, and I only tried it in Ubuntu.

A native and official integration would reduce the CPU penalty of my solution (which is already low), reduce conflicts of several plugins installing their own event loops and enable Blender's event loop to be in total control of task/event scheduling.

Generic Python callbacks for operator calls

Among a lot of other things, operators behave as a concurrency framework and can be seen as "tasks", which are like threads, but in the context of an event loop. However, it is impossible to execute custom Python callbacks at the end of a modal operator call, at least without some very dirty meta programming tricks.

What I mean by this is that a script would invoke an already existing operator, and be notified when this operator exits.

Currently this situation means that scripts can't interact well with modal operators, unless they reimplement them. It's also impossible to wait for the completion of a computationally intensive operator without blocking the user interface.

Support for Cython

In the wider Python community, Cython is becoming the standard way to write native code extensions for Python. Both for speeding up intensive computations and to create bindings to other libraries. It would also allow script authors faster access to blender's memory structures. For example, traversing the network of data structures currently requires allocating and populating Python objects which are discarde immediately. Case in point: Image.pixels requires copying the complete image every time it is accessed from the Image instance, even for one pixel.

Conda

Conda is a binary package manager. It is a lot like pip and virtualenv, but it has better support for binaries, can seperate binary libraries from the rest of the system and supports languages which have nothing to do with Python.

This would solve several problems Blender currently has: The near-impossibility of distributing python plugins with dependencies, let alone binary extensions, incompatibilities of libraries linked into blender and those in system Python, Blender's lack of support for virtualenv and the lack of a package manager in general.

Numpy array access to audio samples

For certain scripts it would be nice to have access to the audio samples. Currently it requires linking to binary Python extensions or running an external process like ffmpeg, creating a big mess.

More Numpy in general

Numpy has a C-API. It is therefore entirely reasonable to store multi-dimensional arrays of internal data in Numpy data structures with virtually no penalty in speed and memory. But it enables easier and faster Python access. I could imagine a Mesh API based around arrays, audio samples, even image data.

In some senses, Numpy is a more sophisticated and mature replacement for Blender's Mathutils.

Again, I know that most of this is not going to happen, but I hope that these suggestions can inspire a bit of debate about the Python API, and what addons can and can't do in Blender.