This indicates at least for people using type checkers that these
classes are not designed for inheritance and we make no stability
guarantees regarding inheritance of them.
Currently this doesn't show up in the docs. Sphinx does actually support
`@final`, however it only works when imported directly from `typing`,
while we import from `_pytest.compat`.
In the future there might also be a `@sealed` decorator which would
cover some more cases.
Usually, we use semi-colon punctuation mark to connect closely related
ideas. Sentences which are after semicolon, begins with small letter,
and last sentence always ends with a period mark, see "Garner's Modern
American Usage" book for more information about usage of punctuation
mark. So removing punctuation mark altogether is a good idea, as
@gnikonorov suggested [1].
[1]: https://github.com/pytest-dev/pytest/pull/7760#pullrequestreview-489232607
For decorated functions, the lineno of the FunctionDef AST node points
to the `def` line, not to the first decorator line. On the other hand,
in code objects, the `co_firstlineno` points to the first decorator
line.
Assertion rewriting inserts some imports to code it rewrites. The
imports are inserted at the lineno of the first statement in the AST. In
turn, the code object compiled from the rewritten AST uses the lineno of
the first statement (which is the first inserted import).
This means that given a module like this,
```py
@foo
@bar
def baz(): pass
```
the lineno of the code object without assertion rewriting
(`--assertion=plain`) is 1, but with assertion rewriting it is 3.
And *this* causes some issues for the exception repr when e.g. the
decorator line is invalid and raises during collection. The code becomes
confused and crashes with
INTERNALERROR> File "_pytest/_code/code.py", line 638, in get_source
INTERNALERROR> lines.append(space_prefix + source.lines[line_index].strip())
INTERNALERROR> IndexError: list index out of range
Fix it by special casing decorators. Maybe there are other cases like
this but off hand I can't think of another Python construct where the
lineno of the item would be after its first line, and this is the only
such issue we have had reported.
- be more vague about "packaging metadata" over explicitly mentioning `setup.py`
(such that `pyproject.toml`-based distributions are allowed)
- drop extensions on `README.txt` / `LICENSE.txt` (it's more common to have `.md`
/ `.rst` / no extension)
- remove duplicate mention of license packaging metadata
