diff --git a/docs/guides/writing_stubs.rst b/docs/guides/writing_stubs.rst index 828db6e1..cebb5222 100644 --- a/docs/guides/writing_stubs.rst +++ b/docs/guides/writing_stubs.rst @@ -93,10 +93,8 @@ Liskov substitutability or detecting problematic overloads. It may be instructive to examine `typeshed `__'s `setup for testing stubs `__. -To suppress type errors on stubs: -* use mypy error codes for mypy-specific `# type: ignore` annotations, e.g. `# type: ignore[override]` for Liskov Substitution Principle violations. -* use pyright error codes for pyright-specific suppressions, e.g. `# pyright: ignore[reportGeneralTypeIssues]`. Pyright is configured to discard `# type: ignore` annotations. -* If you need both on the same line, mypy's annotation needs to go first, e.g. `# type: ignore[override] # pyright: ignore[reportGeneralTypeIssues]`. +To suppress type errors on stubs, use a `# type: ignore` comment. Refer to the style guide for +error suppression formats specific to individual typecheckers. .. TODO: consider adding examples and configurations for specific type checkers @@ -538,7 +536,7 @@ No:: class Foo: # leave only one empty line above x: int - class MyError(Exception): ... + class MyError(Exception): ... # leave an empty line between the classes Module Level Attributes ----------------------- @@ -802,6 +800,14 @@ into any of those categories, use your best judgement. * Use `HasX` for protocols that have readable and/or writable attributes or getter/setter methods (e.g. `HasItems`, `HasFileno`). +Type Checker Error Suppression formats +-------------------------------------- + +* Use mypy error codes for mypy-specific `# type: ignore` annotations, e.g. `# type: ignore[override]` for Liskov Substitution Principle violations. +* Use pyright error codes for pyright-specific suppressions, e.g. `# pyright: ignore[reportGeneralTypeIssues]`. Pyright is configured to discard `# type: ignore` annotations. +* If you need both on the same line, mypy's annotation needs to go first, e.g. `# type: ignore[override] # pyright: ignore[reportGeneralTypeIssues]`. + + `@deprecated` ------------- @@ -809,30 +815,6 @@ The `@typing_extensions.deprecated` decorator (`@warnings.deprecated` since Python 3.13) can be used to mark deprecated functionality; see [PEP 702](https://peps.python.org/pep-0702/). -A few guidelines for how to use it: - -* In the standard library, apply the decorator only in Python versions - where an appropriate replacement for the deprecated functionality - exists. If in doubt, apply the decorator only on versions where the - functionality has been explicitly deprecated, either through runtime - warnings or in the documentation. Use `if sys.version_info` checks to - apply the decorator only to some versions. -* Keep the deprecation message concise, but try to mention the projected - version when the functionality is to be removed, and a suggested - replacement. - -Imports -------- - -Imports in stubs are considered private (not part of the exported API) -unless: -* they use the form ``from library import name as name`` (sic, using explicit ``as`` even if the name stays the same); or -* they use the form ``from library import *`` which means all names from that library are exported. - -Forward References ------------------- - -Stub files support forward references natively. In other words, the -order of class declarations and type aliases does not matter in -a stub file. Unlike regular Python files, you can use the name of the class within its own -body without writing it as a comment. +Keep the deprecation message concise, but try to mention the projected +version when the functionality is to be removed, and a suggested +replacement.