Project import generated by Copybara.

PiperOrigin-RevId: 600882442
This commit is contained in:
Google Python team 2024-01-23 13:03:19 -08:00 committed by Gregory P. Smith [Google LLC]
parent 4d9a47834b
commit 19f31499d7

View File

@ -2093,16 +2093,18 @@ aptly described using a one-line docstring.
: Describe the semantics of the return value, including any type information : Describe the semantics of the return value, including any type information
that the type annotation does not provide. If the function only returns that the type annotation does not provide. If the function only returns
None, this section is not required. It may also be omitted if the docstring None, this section is not required. It may also be omitted if the docstring
starts with Returns or Yields (e.g. `"""Returns row from Bigtable as a tuple starts with "Return", "Returns", "Yield", or "Yields" (e.g. `"""Returns row
of strings."""`) and the opening sentence is sufficient to describe the from Bigtable as a tuple of strings."""`) *and* the opening sentence is
return value. Do not imitate older 'NumPy style' sufficient to describe the return value. Do not imitate older 'NumPy style'
([example](https://numpy.org/doc/1.24/reference/generated/numpy.linalg.qr.html)), ([example](https://numpy.org/doc/1.24/reference/generated/numpy.linalg.qr.html)),
which frequently documented a tuple return value as if it were multiple which frequently documented a tuple return value as if it were multiple
return values with individual names (never mentioning the tuple). Instead, return values with individual names (never mentioning the tuple). Instead,
describe such a return value as: "Returns: A tuple (mat_a, mat_b), where describe such a return value as: "Returns: A tuple (mat_a, mat_b), where
mat_a is ..., and ...". The auxiliary names in the docstring need not mat_a is ..., and ...". The auxiliary names in the docstring need not
necessarily correspond to any internal names used in the function body (as necessarily correspond to any internal names used in the function body (as
those are not part of the API). those are not part of the API). If the function uses `yield` (is a
generator), the `Yields:` section should document the object returned by
`next()`, instead of the generator object itself that the call evaluates to.
<a id="doc-function-raises"></a> <a id="doc-function-raises"></a>
[*Raises:*](#doc-function-raises) [*Raises:*](#doc-function-raises)
@ -2539,7 +2541,7 @@ messages shown to the user) should follow three guidelines:
```python ```python
Yes: Yes:
if not 0 <= p <= 1: if not 0 <= p <= 1:
raise ValueError(f'Not a probability: {p!r}') raise ValueError(f'Not a probability: {p=}')
try: try:
os.rmdir(workdir) os.rmdir(workdir)
@ -2551,7 +2553,7 @@ messages shown to the user) should follow three guidelines:
```python ```python
No: No:
if p < 0 or p > 1: # PROBLEM: also false for float('nan')! if p < 0 or p > 1: # PROBLEM: also false for float('nan')!
raise ValueError(f'Not a probability: {p!r}') raise ValueError(f'Not a probability: {p=}')
try: try:
os.rmdir(workdir) os.rmdir(workdir)
@ -3114,13 +3116,20 @@ the function into smaller and more manageable pieces.
* Familiarize yourself with [PEP-484](https://peps.python.org/pep-0484/). * Familiarize yourself with [PEP-484](https://peps.python.org/pep-0484/).
* In methods, only annotate `self`, or `cls` if it is necessary for proper * Annotating `self` or `cls` is generally not necessary.
type information. e.g., [`Self`](https://docs.python.org/3/library/typing.html#typing.Self) can be
used if it is necessary for proper type information, e.g.
```python ```python
@classmethod from typing import Self
def create(cls: Type[_T]) -> _T:
return cls() class BaseClass:
@classmethod
def create(cls) -> Self:
...
def difference(self, other: Self) -> float:
...
``` ```
* Similarly, don't feel compelled to annotate the return value of `__init__` * Similarly, don't feel compelled to annotate the return value of `__init__`