mirror of
https://github.com/google/styleguide.git
synced 2024-03-22 13:11:43 +08:00
Project import generated by Copybara.
PiperOrigin-RevId: 600882442
This commit is contained in:
parent
4d9a47834b
commit
19f31499d7
29
pyguide.md
29
pyguide.md
|
@ -2093,16 +2093,18 @@ aptly described using a one-line docstring.
|
|||
: Describe the semantics of the return value, including any type information
|
||||
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
|
||||
starts with Returns or Yields (e.g. `"""Returns row from Bigtable as a tuple
|
||||
of strings."""`) and the opening sentence is sufficient to describe the
|
||||
return value. Do not imitate older 'NumPy style'
|
||||
starts with "Return", "Returns", "Yield", or "Yields" (e.g. `"""Returns row
|
||||
from Bigtable as a tuple of strings."""`) *and* the opening sentence is
|
||||
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)),
|
||||
which frequently documented a tuple return value as if it were multiple
|
||||
return values with individual names (never mentioning the tuple). Instead,
|
||||
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
|
||||
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>
|
||||
[*Raises:*](#doc-function-raises)
|
||||
|
@ -2539,7 +2541,7 @@ messages shown to the user) should follow three guidelines:
|
|||
```python
|
||||
Yes:
|
||||
if not 0 <= p <= 1:
|
||||
raise ValueError(f'Not a probability: {p!r}')
|
||||
raise ValueError(f'Not a probability: {p=}')
|
||||
|
||||
try:
|
||||
os.rmdir(workdir)
|
||||
|
@ -2551,7 +2553,7 @@ messages shown to the user) should follow three guidelines:
|
|||
```python
|
||||
No:
|
||||
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:
|
||||
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/).
|
||||
|
||||
* In methods, only annotate `self`, or `cls` if it is necessary for proper
|
||||
type information. e.g.,
|
||||
* Annotating `self` or `cls` is generally not necessary.
|
||||
[`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
|
||||
from typing import Self
|
||||
|
||||
class BaseClass:
|
||||
@classmethod
|
||||
def create(cls: Type[_T]) -> _T:
|
||||
return cls()
|
||||
def create(cls) -> Self:
|
||||
...
|
||||
|
||||
def difference(self, other: Self) -> float:
|
||||
...
|
||||
```
|
||||
|
||||
* Similarly, don't feel compelled to annotate the return value of `__init__`
|
||||
|
|
Loading…
Reference in New Issue
Block a user