|
1 |
| -(function-and-method-signatures)= |
| 1 | +.. _function-and-method-signatures: |
2 | 2 |
|
3 |
| -# Function and method signatures |
| 3 | +Function and method signatures |
| 4 | +============================== |
4 | 5 |
|
5 | 6 | Function signatures in this standard adhere to the following:
|
6 | 7 |
|
7 |
| -1. Positional parameters must be |
8 |
| - [positional-only](https://www.python.org/dev/peps/pep-0570/) parameters. |
| 8 | +1. Positional parameters must be `positional-only <https://www.python.org/dev/peps/pep-0570/>`_ parameters. |
9 | 9 | Positional-only parameters have no externally-usable name. When a function
|
10 | 10 | accepting positional-only parameters is called, positional arguments are
|
11 | 11 | mapped to these parameters based solely on their order.
|
12 | 12 |
|
13 |
| - _Rationale: existing libraries have incompatible conventions, and using names |
14 |
| - of positional parameters is not normal/recommended practice._ |
| 13 | + *Rationale: existing libraries have incompatible conventions, and using names |
| 14 | + of positional parameters is not normal/recommended practice.* |
15 | 15 |
|
16 |
| - ```{note} |
| 16 | +.. note:: |
17 | 17 |
|
18 | 18 | Positional-only parameters are only available in Python >= 3.8. Libraries
|
19 | 19 | still supporting 3.7 or 3.6 may consider making the API standard-compliant
|
20 | 20 | namespace >= 3.8. Alternatively, they can add guidance to their users in the
|
21 |
| - documentation to use the functions as if they were positional-only. |
22 |
| - ``` |
| 21 | + documentation to use the functions as if they were positional-only. |
23 | 22 |
|
24 |
| -2. Optional parameters must be |
25 |
| - [keyword-only](https://www.python.org/dev/peps/pep-3102/) arguments. |
| 23 | +2. Optional parameters must be `keyword-only <https://www.python.org/dev/peps/pep-3102/>`_ arguments. |
26 | 24 |
|
27 |
| - _Rationale: this leads to more readable code, and it makes it easier to |
| 25 | + *Rationale: this leads to more readable code, and it makes it easier to |
28 | 26 | evolve an API over time by adding keywords without having to worry about
|
29 |
| - keyword order._ |
| 27 | + keyword order.* |
30 | 28 |
|
31 | 29 | 3. For functions that have a single positional array parameter, that parameter
|
32 |
| - is called `x`. For functions that have multiple array parameters, those |
33 |
| - parameters are called `xi` with `i = 1, 2, ...` (i.e., `x1`, `x2`). |
| 30 | + is called ``x``. For functions that have multiple array parameters, those |
| 31 | + parameters are called ``xi`` with ``i = 1, 2, ...`` (i.e., ``x1``, ``x2``). |
34 | 32 |
|
35 | 33 | 4. Type annotations are left out of the signatures themselves for readability; however,
|
36 | 34 | they are added to individual parameter descriptions. For code which aims to
|
37 | 35 | adhere to the standard, adding type annotations is strongly recommended.
|
38 | 36 |
|
39 | 37 | A function signature and description will look like:
|
40 | 38 |
|
41 |
| -``` |
42 |
| -funcname(x1, x2, /, *, key1=-1, key2=None) |
| 39 | +:: |
43 | 40 |
|
44 |
| - Parameters |
| 41 | + funcname(x1, x2, /, *, key1=-1, key2=None) -> out: |
| 42 | + Parameters |
45 | 43 |
|
46 |
| - x1 : array |
47 |
| - description |
48 |
| - x2 : array |
49 |
| - description |
50 |
| - key1 : int |
51 |
| - description |
52 |
| - key2 : Optional[str] |
53 |
| - description |
| 44 | + x1 : array |
| 45 | + description |
| 46 | + x2 : array |
| 47 | + description |
| 48 | + key1 : int |
| 49 | + description |
| 50 | + key2 : Optional[str] |
| 51 | + description |
54 | 52 |
|
55 |
| - Returns |
| 53 | + Returns |
56 | 54 |
|
57 |
| - out : array |
58 |
| - description |
59 |
| -``` |
| 55 | + out : array |
| 56 | + description |
60 | 57 |
|
61 |
| -Method signatures will follow the same conventions modulo the addition of |
62 |
| -`self`. |
| 58 | + |
| 59 | +Method signatures will follow the same conventions modulo the addition of ``self``. |
0 commit comments