uarray

Warning

uarray is a developer tool, it is not meant to be used directly by end-users.

Warning

This document is meant to elicit discussion from the broader community and to help drive the direction that uarray goes towards. Examples provided here may not be immediately stable.

Note

This page describes the overall philosophy behind uarray. For usage instructions, see the uarray API documentation page. If you are interested in augmentation for NEP-22, please see the unumpy page.

uarray is a backend system for Python that allows you to separately define an API, along with backends that contain separate implementations of that API.

unumpy builds on top of uarray. It is an effort to specify the core NumPy API, and provide backends for the API.

What’s new in uarray?

uarray is, to our knowledge, the first backend-system for Python that’s generic enough to cater to the use-cases of many libraries, while at the same time, being library independent.

unumpy is the first approach to leverage uarray in order to build a generic backend system for (what we hope will be) the core NumPy API. It will be possible to create a backend object and use that to perform operations. In addition, it will be possible to change the used backend via a context manager.

Benefits for end-users

End-users can easily take their code written for one backend and use it on another backend with a simple switch (using a Python context manager). This can have any number of effects, depending on the functionality of the library. For example:

  • For Matplotlib, changing styles of plots or producing different windows or image formats.

  • For Tensorly, providing a different computation backend that can be distributed or target the GPU or sparse arrays.

  • For unumpy, it can do a similar thing: provide users with code they already wrote for numpy and easily switch to a different backend.

Benefits for library authors

To library authors, the benefits come in two forms: First, it allows them to build their libraries to be implementation independent. In code that builds itself on top of unumpy, it would be very easy to target the GPU, use sparse arrays or do any kind of distributed computing.

The second is to allow a way to separate the interface from implementation, and easily allow a way to switch an implementation.

Relation to the NumPy duck-array ecosystem

uarray is a backend/dispatch mechanism with a focus on array computing and the needs of the wider array community, by allowing a clean way to register an implementation for any Python object (functions, classes, class methods, properties, dtypes, …), it also provides an important building block for NEP-22. It is meant to address the shortcomings of NEP-18 and NEP-13; while still holding nothing in uarray itself that’s specific to array computing or the NumPy API.

Where to from here?

Choose the documentation page relevant to you:

Indices and tables