8000 Add content from typeshed/CONTRIBUTING.md by yangdanny97 · Pull Request #1882 · python/typing · GitHub
[go: up one dir, main page]

Skip to content

Add content from typeshed/CONTRIBUTING.md #1882

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 15 commits into from
Dec 17, 2024
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
address review comments
  • Loading branch information
yangdanny97 committed Dec 7, 2024
commit cfc2827a630973e8624235f2c3339716856c5b11
46 changes: 14 additions & 32 deletions docs/guides/writing_stubs.rst
Original file line number Diff line number Diff line change
Expand Up @@ -93,10 +93,8 @@ Liskov substitutability or detecting problematic overloads.
It may be instructive to examine `typeshed <https://github.com/python/typeshed/>`__'s
`setup for testing stubs <https://github.com/python/typeshed/blob/main/tests/README.md>`__.

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
Expand Down Expand Up @@ -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
-----------------------
Expand Down Expand Up @@ -802,37 +800,21 @@ 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`
-------------

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 explic 8000 it ``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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we say that if a deprecated feature is still very widely used and was deprecated only recently, it may be best to wait before adding @deprecated?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think so. If the feature is still in wide use, that's an argument against deprecating the feature, but if the runtime code decides to deprecate something, the stubs should communicate that fact.

Loading
0