Contents

• Abstract
• Motivation
• Summary Examples
• Specification
  • Type Variable Tuples
    • Type Variable Tuples Must Always be Unpacked
    • Unpack for Backwards Compatibility
    • Variance, Type Constraints and Type Bounds: Not (Yet) Supported
    • Behaviour when Type Parameters are not Specified
    • Type Variable Tuples Must Have Known Length
    • Type Variable Tuple Equality
    • Multiple Type Variable Tuples: Not Allowed
  • Type Concatenation
  • *args as a Type Variable Tuple
  • Type Variable Tuples with Callable
  • Aliases
  • Overloads for Accessing Individual Types
• Rationale and Rejected Ideas
  • Shape Arithmetic
  • Supporting Variadicity Through Aliases
  • Construction of TypeVarTuple
  • Behaviour when Type Parameters are not Specified
• Alternatives
• Grammar Changes
  • Change 1: Star Expressions in Indexes
    • TypeVarTuple Implementation
    • Implications
  • Change 2: *args as a TypeVarTuple
    • Implications
  • Alternatives (Why Not Just Use Unpack?)
• Backwards Compatibility
• Reference Implementation
• Appendix A: Shape Typing Use Cases
  • Use Case 1: Specifying Shape Values
  • Use Case 2: Specifying Shape Semantics
  • Discussion
  • Why Not Both?
• Appendix B: Shaped Types vs Named Axes
• Footnotes
• Endorsements
• Acknowledgements
• Resources
• References
• Copyright

Abstract

PEP 484 introduced TypeVar, enabling creation of generics parameterised with a single type. In this PEP, we introduce TypeVarTuple, enabling parameterisation with an arbitrary number of types - that is, a variadic type variable, enabling variadic generics. This enables a wide variety of use cases. In particular, it allows the type of array-like structures in numerical computing libraries such as NumPy and TensorFlow to be parameterised with the array shape, enabling static type checkers to catch shape-related bugs in code that uses these libraries.

Motivation

Variadic generics have long been a requested feature, for a myriad of use cases 4. One particular use case - a use case with potentially large impact, and the main case this PEP targets - concerns typing in numerical libraries.

In the context of numerical computation with libraries such as NumPy and TensorFlow, the shape of variables is often just as important as the variable type. For example, consider the following function which converts a batch 1 of videos to grayscale:

def to_gray(videos: Array): ...

From the signature alone, it is not obvious what shape of array 2 we should pass for the videos argument. Possibilities include, for example,

batch × time × height × width × channels

and

time × batch × channels × height × width. 3

This is important for three reasons:

• Documentation. Without the required shape being clear in the signature, the user must hunt in the docstring or the code in question to determine what the input/output shape requirements are.
• Catching shape bugs before runtime. Ideally, use of incorrect shapes should be an error we can catch ahead of time using static analysis. (This is particularly important for machine learning code, where iteration times can be slow.)
• Preventing subtle shape bugs. In the worst case, use of the wrong shape will result in the program appearing to run fine, but with a subtle bug that can take days to track down. (See this exercise 18 in a popular machine learning tutorial for a particularly pernicious example.)

Ideally, we should have some way of making shape requirements explicit in type signatures. Multiple proposals 6 7 9 have suggested the use of the standard generics syntax for this purpose. We would write:

def to_gray(videos: Array[Time, Batch, Height, Width, Channels]): ...

However, note that arrays can be of arbitrary rank - Array as used above is generic in an arbitrary number of axes. One way around this would be to use a different Array class for each rank…

Axis1 = TypeVar('Axis1')
Axis2 = TypeVar('Axis2')

class Array1(Generic[Axis1]): ...

class Array2(Generic[Axis1, Axis2]): ...

…but this would be cumbersome, both for users (who would have to sprinkle 1s and 2s and so on throughout their code) and for the authors of array libraries (who would have to duplicate implementations throughout multiple classes).

Variadic generics are necessary for an Array that is generic in an arbitrary number of axes to be cleanly defined as a single class.

Summary Examples

Cutting right to the chase, this PEP allows an Array class that is generic in its shape (and datatype) to be defined using a newly-introduced arbitrary-length type variable, TypeVarTuple, as follows:

from typing import TypeVar, TypeVarTuple

DType = TypeVar('DType')
Shape = TypeVarTuple('Shape')

class Array(Generic[DType, *Shape]):

    def __abs__(self) -> Array[DType, *Shape]: ...

    def __add__(self, other: Array[DType, *Shape]) -> Array[DType, *Shape]: ...

Such an Array can be used to support a number of different kinds of shape annotations. For example, we can add labels describing the semantic meaning of each axis:

from typing import NewType

Height = NewType('Height', int)
Width = NewType('Width', int)

x: Array[float, Height, Width] = Array()

We could also add annotations describing the actual size of each axis:

from typing import Literal as L


x: Array[float, L[480], L[640]] = Array()

For consistency, we use semantic axis annotations as the basis of the examples in this PEP, but this PEP is agnostic about which of these two (or possibly other) ways of using Array is preferable; that decision is left to library authors.

(Note also that for the rest of this PEP, for conciseness of example, we use a simpler version of Array which is generic only in the shape - not the data type.)

Specification

In order to support the above use cases, we introduce TypeVarTuple. This serves as a placeholder not for a single type but for an arbitrary number of types, and behaving like a number of TypeVar instances packed in a Tuple.

In addition, we introduce a new use for the star operator: to ‘unpack’ TypeVarTuple instances, in order to access the type variables contained in the tuple.

from typing import TypeVarTuple

Ts = TypeVarTuple('Ts')

Shape = TypeVarTuple('Shape')

class Array(Generic[*Shape]): ...

Height = NewType('Height', int)
Width = NewType('Width', int)
x: Array[Height, Width] = Array()

Time = NewType('Time', int)
Batch = NewType('Batch', int)
y: Array[Batch, Height, Width] = Array()
z: Array[Time, Batch, Height, Width] = Array()

class Array(Generic[*Shape]):

    def __init__(self, shape: Tuple[*Shape]):
        self._shape: Tuple[*Shape] = shape

    def get_shape(self) -> Tuple[*Shape]:
        return self._shape

shape = (Height(480), Width(640))
x: Array[Height, Width] = Array(shape)
y = abs(x)  # Inferred type is Array[Height, Width]
z = x + x   #        ...    is Array[Height, Width]

# Unpacking using the star operator in new versions of Python
class Array(Generic[*Shape]): ...

# Unpacking using ``Unpack`` in older versions of Python
class Array(Generic[Unpack[Shape]]): ...

def takes_any_array(arr: Array): ...

x: Array[Height, Width]
takes_any_array(x)  # Valid
y: Array[Time, Height, Width]
takes_any_array(y)  # Also valid

def takes_specific_array(arr: Array[Height, Width]): ...

z: Array
takes_specific_array(z)

def foo(x: Tuple[*Ts]): ...

x: Tuple[float, ...]
foo(x)  # NOT valid; Ts would be bound to ``Tuple[float, ...]``

x: Array            # Valid
y: Array[int, ...]  # Error
z: Array[Any, ...]  # Error

def foo(arg1: Tuple[*Ts], arg2: Tuple[*Ts]): ...

a = (0,)
b = ('0',)
foo(a, b)  # Can Ts be bound to Tuple[int | str]?

def pointwise_multiply(
    x: Array[*Shape],
    y: Array[*Shape]
) -> Array[*Shape]: ...

x: Array[Height]
y: Array[Width]
z: Array[Height, Width]
pointwise_multiply(x, x)  # Valid
pointwise_multiply(x, y)  # Error
pointwise_multiply(x, z)  # Error

class Array(Generic[*Ts1, *Ts2]): ...  # Error

Shape = TypeVarTuple('Shape')
Batch = NewType('Batch', int)
Channels = NewType('Channels', int)

def add_batch_axis(x: Array[*Shape]) -> Array[Batch, *Shape]: ...
def del_batch_axis(x: Array[Batch, *Shape]) -> Array[*Shape]: ...
def add_batch_channels(
  x: Array[*Shape]
) -> Array[Batch, *Shape, Channels]: ...

a: Array[Height, Width]
b = add_batch_axis(a)      # Inferred type is Array[Batch, Height, Width]
c = del_batch_axis(b)      # Array[Height, Width]
d = add_batch_channels(a)  # Array[Batch, Height, Width, Channels]

T = TypeVar('T')
Ts = TypeVarTuple('Ts')

def prefix_tuple(
    x: T,
    y: Tuple[*Ts]
) -> Tuple[T, *Ts]: ...

z = prefix_tuple(x=0, y=(True, 'a'))
# Inferred type of z is Tuple[int, bool, str]

Ts = TypeVarTuple('Ts')

def args_to_tuple(*args: *Ts) -> Tuple[*Ts]: ...

args_to_tuple(1, 'a')  # Inferred type is Tuple[int, str]

def foo(*args: Ts): ...  # NOT valid

def foo(*args: Tuple[*Ts]): ...

foo((0,), (1,))    # Valid
foo((0,), (1, 2))  # Error
foo((0,), ('1',))  # Error

def foo(*args: *Ts): ...

def bar(x: Tuple[int, ...]):
  foo(*x)  # NOT valid

# NOT valid
def foo(**kwargs: *Ts): ...

class Process:
  def __init__(
    self,
    target: Callable[[*Ts], Any],
    args: Tuple[*Ts]
  ): ...

def func(arg1: int, arg2: str): ...

Process(target=func, args=(0, 'foo'))  # Valid
Process(target=func, args=('foo', 0))  # Error

T = TypeVar('T')

def foo(f: Callable[[int, *Ts, T], Tuple[T, *Ts]]): ...

IntTuple = Tuple[int, *Ts]
NamedArray = Tuple[str, Array[*Ts]]

IntTuple[float, bool]  # Equivalent to Tuple[int, float, bool]
NamedArray[Height]     # Equivalent to Tuple[str, Array[Height]]

Shape = TypeVarTuple('Shape')
DType = TypeVar('DType')
class Array(Generic[DType, *Shape]):

# E.g. Float32Array[Height, Width, Channels]
Float32Array = Array[np.float32, *Shape]

# E.g. Array1D[np.uint8]
Array1D = Array[DType, Any]

IntTuple[()]    # Equivalent to Tuple[int]
NamedArray[()]  # Equivalent to Tuple[str, Array[()]]

def takes_float_array_of_any_shape(x: Float32Array): ...
x: Float32Array[Height, Width] = Array()
takes_float_array_of_any_shape(x)  # Valid

def takes_float_array_with_specific_shape(
    y: Float32Array[Height, Width]
): ...
y: Float32Array = Array()
takes_float_array_with_specific_shape(y)  # Valid

T = TypeVar('T')
Foo = Tuple[T, *Ts]

# T bound to str, Ts to Tuple[int]
Foo[str, int]
# T bound to float, Ts to Tuple[()]
Foo[float]
# T bound to Any, Ts to an arbitrary number of Any
Foo

Shape = TypeVarTuple('Shape')
Axis1 = TypeVar('Axis1')
Axis2 = TypeVar('Axis2')
Axis3 = TypeVar('Axis3')

class Array(Generic[*Shape]):

  @overload
  def transpose(
    self: Array[Axis1, Axis2]
  ) -> Array[Axis2, Axis1]: ...

  @overload
  def transpose(
    self: Array[Axis1, Axis2, Axis3]
  ) -> Array[Axis3, Axis2, Axis1]: ...

Rationale and Rejected Ideas

class Array1(Generic[Axis1]): ...
class Array2(Generic[Axis1, Axis2]): ...

def takes_any_array(x: Array): ...
x: Array[Height, Width]
takes_any_array(x)

def takes_specific_array(y: Array[Height, Width]): ...
y: Array
takes_specific_array(y)

def takes_any_tuple(x: Tuple): ...
x: Tuple[int, str]
takes_any_tuple(x)  # Valid

def takes_specific_tuple(y: Tuple[int, str]): ...
y: Tuple
takes_specific_tuple(y)  # Error

Alternatives

It should be noted that the approach outlined in this PEP to solve the issue of shape checking in numerical libraries is not the only approach possible. Examples of lighter-weight alternatives based on runtime checking include ShapeGuard 13, tsanley 11, and PyContracts 12.

While these existing approaches improve significantly on the default situation of shape checking only being possible through lengthy and verbose assert statements, none of them enable static analysis of shape correctness. As mentioned in Motivation, this is particularly desirable for machine learning applications where, due to library and infrastructure complexity, even relatively simple programs must suffer long startup times; iterating by running the program until it crashes, as is necessary with these existing runtime-based approaches, can be a tedious and frustrating experience.

Our hope with this PEP is to begin to codify generic type annotations as an official, language-supported way of dealing with shape correctness. With something of a standard in place, in the long run, this will hopefully enable a thriving ecosystem of tools for analysing and verifying shape properties of numerical computing programs.

Grammar Changes

This PEP requires two grammar changes. Full diffs of python.gram and simple tests to confirm correct behaviour are available at https://github.com/mrahtz/cpython/commits/pep646-grammar.

DType = TypeVar('DType')
Shape = TypeVarTuple('Shape')
class Array(Generic[DType, *Shape]):
    ...

slices:
    | slice !','
    | ','.slice+ [',']

slices:
    | slice !','
    | ','.(slice | starred_expression)+ [',']

class TypeVarTuple:
    def __init__(self, name):
        self._name = name
        self._unpacked = UnpackedTypeVarTuple(name)
    def __iter__(self):
        yield self._unpacked
    def __repr__(self):
        return self._name

class UnpackedTypeVarTuple:
    def __init__(self, name):
        self._name = name
    def __repr__(self):
        return '*' + self._name

idxs_to_select = (1, 2)
array[0, *idxs_to_select, -1]  # Equivalent to [0, 1, 2, -1]

array[*idxs_to_select, *idxs_to_select]  # Equivalent to array[1, 2, 1, 2]

array[3:5, *idxs_to_select]  # Equivalent to array[3:5, 1, 2]

# Syntax error
array[*idxs_start:*idxs_end]

star_etc:
| '*' param_no_default param_maybe_default* [kwds]
| '*' ',' param_maybe_default+ [kwds]
| kwds

star_etc:
| '*' param_no_default param_maybe_default* [kwds]
| '*' param_no_default_star_annotation param_maybe_default* [kwds]  # New
| '*' ',' param_maybe_default+ [kwds]
| kwds

param_no_default_star_annotation:
| param_star_annotation ',' TYPE_COMMENT?
| param_star_annotation TYPE_COMMENT? &')'

param_star_annotation: NAME star_annotation

star_annotation: ':' star_expression

>>> Ts = TypeVarTuple('Ts')
>>> def foo(*args: *Ts): pass  # Equivalent to `*args: tuple(Ts)`
>>> foo.__annotations__
{'args': (*Ts,)}
# *Ts is the repr() of Ts._unpacked, an instance of UnpackedTypeVarTuple

x: *Ts                 # Syntax error
def foo(x: *Ts): pass  # Syntax error

>>> foo = [1, 2, 3]
>>> def bar(*args: *foo): pass  # Equivalent to `*args: tuple(foo)`
>>> bar.__annotations__
{'args': (1, 2, 3)}

Backwards Compatibility

The Unpack version of the PEP should be back-portable to previous versions of Python.

Gradual typing is enabled by the fact that unparameterised variadic classes are compatible with an arbitrary number of type parameters. This means that if existing classes are made generic, a) all existing (unparameterised) uses of the class will still work, and b) parameterised and unparameterised versions of the class can be used together (relevant if, for example, library code is updated to use parameters while user code is not, or vice-versa).

Reference Implementation

Two reference implementations of type-checking functionality exist: one in Pyre, as of v0.9.0, and one in Pyright, as of v1.1.108.

A preliminary implementation of the Unpack version of the PEP in CPython is available in cpython/23527 16. A preliminary version of the version using the star operator, based on an early implementation of PEP 637, is also available at mrahtz/cpython/pep637+646 17.

Appendix A: Shape Typing Use Cases

To give this PEP additional context for those particularly interested in the array typing use case, in this appendix we expand on the different ways this PEP can be used for specifying shape-based subtypes.

K = TypeVar('K')
N = TypeVar('N')

def matrix_vector_multiply(x: Array[K, N], Array[N]) -> Array[K]: ...

a: Array[Literal[64], Literal[32]]
b: Array[Literal[32]]
matrix_vector_multiply(a, b)
# Result is Array[Literal[64]]

def repeat_each_element(x: Array[N]) -> Array[Mul[2, N]]: ...

# lib.py

class Batch: pass
class Time: pass

def make_array() -> Array[Batch, Time]: ...

# user.py

from lib import Batch, Time

# `Batch` and `Time` have the same identity as in `lib`,
# so must take array as produced by `lib.make_array`
def use_array(x: Array[Batch, Time]): ...

K = TypeVar('K')
N = TypeVar('N')

def matrix_vector_multiply(x: Array[K, N], Array[N]) -> Array[K]: ...

def f(x: int): ...

def f(array: Array[TimeValue: TimeType]): ...

def f(array: array[TimeValue[TimeType]]): ..

Appendix B: Shaped Types vs Named Axes

An issue related to those addressed by this PEP concerns axis selection. For example, if we have an image stored in an array of shape 64×64x3, we might wish to convert to black-and-white by computing the mean over the third axis, mean(image, axis=2). Unfortunately, the simple typo axis=1 is difficult to spot and will produce a result that means something completely different (all while likely allowing the program to keep on running, resulting in a bug that is serious but silent).

In response, some libraries have implemented so-called ‘named tensors’ (in this context, ‘tensor’ is synonymous with ‘array’), in which axes are selected not by index but by label - e.g. mean(image, axis='channels').

A question we are often asked about this PEP is: why not just use named tensors? The answer is that we consider the named tensors approach insufficient, for two main reasons:

• Static checking of shape correctness is not possible. As mentioned in Motivation, this is a highly desirable feature in machine learning code where iteration times are slow by default.
• Interface documentation is still not possible with this approach. If a function should only be willing to take array arguments that have image-like shapes, this cannot be stipulated with named tensors.

Additionally, there’s the issue of poor uptake. At the time of writing, named tensors have only been implemented in a small number of numerical computing libraries. Possible explanations for this include difficulty of implementation (the whole API must be modified to allow selection by axis name instead of index), and lack of usefulness due to the fact that axis ordering conventions are often strong enough that axis names provide little benefit (e.g. when working with images, 3D tensors are basically always height × width × channels). However, ultimately we are still uncertain why this is the case.

Can the named tensors approach be combined with the approach we advocate for in this PEP? We’re not sure. One area of overlap is that in some contexts, we could do, say:

Image: Array[Height, Width, Channels]
im: Image
mean(im, axis=Image.axes.index(Channels)

Ideally, we might write something like im: Array[Height=64, Width=64, Channels=3] - but this won’t be possible in the short term, due to the rejection of PEP 637. In any case, our attitude towards this is mostly “Wait and see what happens before taking any further steps”.

Footnotes

1

‘Batch’ is machine learning parlance for ‘a number of’.

2

We use the term ‘array’ to refer to a matrix with an arbitrary number of dimensions. In NumPy, the corresponding class is the ndarray; in TensorFlow, the Tensor; and so on.

3

If the shape begins with ‘batch × time’, then videos_batch[0][1] would select the second frame of the first video. If the shape begins with ‘time × batch’, then videos_batch[1][0] would select the same frame.

Endorsements

Variadic generics have a wide range of uses. For the fraction of that range involving numerical computing, how likely is it that relevant libraries will actually make use of the features proposed in this PEP?

We reached out to a number of people with this question, and received the following endorsements.

From Stephan Hoyer, member of the NumPy Steering Council: 14

I just wanted to thank Matthew & Pradeep for writing this PEP and for clarifications to the broader context of PEP 646 for array typing in https://github.com/python/peps/pull/1904.

As someone who is heavily involved in the Python numerical computing community (e.g., NumPy, JAX, Xarray), but who is not so familiar with the details of Python’s type system, it is reassuring to see that a broad range of use-cases related to type checking of named axes & shapes have been considered, and could build upon the infrastructure in this PEP.

Type checking for shapes is something the NumPy community is very interested in – there are more thumbs up on the relevant issue on NumPy’s GitHub than any others (https://github.com/numpy/numpy/issues/7370) and we recently added a “typing” module that is under active development.

It will certainly require experimentation to figure out the best ways to use type checking for ndarrays, but this PEP looks like an excellent foundation for such work.

From Bas van Beek, who has worked on preliminary support for shape-generics in NumPy:

I very much share Stephan’s opinion here and look forward to integrating the new PEP 646 variadics into numpy.

In the context of numpy (and tensor typing general): the typing of array shapes is a fairly complicated subject and the introduction of variadics will likely play in big role in laying its foundation, as it allows for the expression of both dimensioability as well as basic shape manipulation.

All in all, I’m very interested in where both PEP 646 and future PEPs will take us and look forward to further developments.

From Dan Moldovan, a Senior Software Engineer on the TensorFlow Dev Team and author of the TensorFlow RFC, TensorFlow Canonical Type System 19: 15

I’d be interested in using this the mechanisms defined in this PEP to define rank-generic Tensor types in TensorFlow, which are important in specifying tf.function signatures in a Pythonic way, using type annotations (rather than the custom input_signature mechanism we have today - see this issue: https://github.com/tensorflow/tensorflow/issues/31579). Variadic generics are among the last few missing pieces to create an elegant set of type definitions for tensors and shapes.

(For the sake of transparency - we also reached out to folks from a third popular numerical computing library, PyTorch, but did not receive a statement of endorsement from them. Our understanding is that although they are interested in some of the same issues - e.g. static shape inference - they are currently focusing on enabling this through a DSL rather than the Python type system.)

Acknowledgements

Thank you to Alfonso Castaño, Antoine Pitrou, Bas v.B., David Foster, Dimitris Vardoulakis, Eric Traut, Guido van Rossum, Jia Chen, Lucio Fernandez-Arjona, Nikita Sobolev, Peilonrayz, Rebecca Chen, Sergei Lebedev, and Vladimir Mikulik for helpful feedback and suggestions on drafts of this PEP.

Thank you especially to Lucio for suggesting the star syntax (which has made multiple aspects of this proposal much more concise and intuitive), and to Stephan Hoyer and Dan Moldovan for their endorsements.

Resources

Discussions on variadic generics in Python started in 2016 with Issue 193 on the python/typing GitHub repository 4.

Inspired by this discussion, Ivan Levkivskyi made a concrete proposal at PyCon 2019, summarised in notes on ‘Type system improvements’ 5 and ‘Static typing of Python numeric stack’ 6.

Expanding on these ideas, Mark Mendoza and Vincent Siles gave a presentation on ‘Variadic Type Variables for Decorators and Tensors’ 8 at the 2019 Python Typing Summit.

References

4 (1, 2)

Python typing issue #193: https://github.com/python/typing/issues/193

5

Ivan Levkivskyi, ‘Type system improvements’, PyCon 2019: https://paper.dropbox.com/doc/Type-system-improvements-HHOkniMG9WcCgS0LzXZAe

6 (1, 2)

Ivan Levkivskyi, ‘Static typing of Python numeric stack’, PyCon 2019: https://paper.dropbox.com/doc/Static-typing-of-Python-numeric-stack-summary-6ZQzTkgN6e0oXko8fEWwN

7

Stephan Hoyer, ‘Ideas for array shape typing in Python’: https://docs.google.com/document/d/1vpMse4c6DrWH5rq2tQSx3qwP_m_0lyn-Ij4WHqQqRHY/edit

8

Mark Mendoza, ‘Variadic Type Variables for Decorators and Tensors’, Python Typing Summit 2019: https://github.com/facebook/pyre-check/blob/ae85c0c6e99e3bbfc92ec55104bfdc5b9b3097b2/docs/Variadic_Type_Variables_for_Decorators_and_Tensors.pdf

9

Matthew Rahtz et al., ‘Shape annotation syntax proposal’: https://docs.google.com/document/d/1But-hjet8-djv519HEKvBN6Ik2lW3yu0ojZo6pG9osY/edit

10

Discussion on Python typing-sig mailing list: https://mail.python.org/archives/list/typing-sig@python.org/thread/SQVTQYWIOI4TIO7NNBTFFWFMSMS2TA4J/

11

tsanley: https://github.com/ofnote/tsanley

12

PyContracts: https://github.com/AndreaCensi/contracts

13

ShapeGuard: https://github.com/Qwlouse/shapeguard

14

https://mail.python.org/archives/list/python-dev@python.org/message/UDM7Y6HLHQBKXQEBIBD5ZLB5XNPDZDXV/

15

https://mail.python.org/archives/list/python-dev@python.org/message/HTCARTYYCHETAMHB6OVRNR5EW5T2CP4J/

16

https://github.com/python/cpython/pull/24527

17

https://github.com/mrahtz/cpython/tree/pep637%2B646

18

https://spinningup.openai.com/en/latest/spinningup/exercise2_2_soln.html

19

https://github.com/tensorflow/community/pull/208

Copyright

This document is placed in the public domain or under the CC0-1.0-Universal license, whichever is more permissive.