You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: doc/source/development/contributing_codebase.rst
+18-61
Original file line number
Diff line number
Diff line change
@@ -18,40 +18,31 @@ tools will be run to check your code for stylistic errors.
18
18
Generating any warnings will cause the test to fail.
19
19
Thus, good style is a requirement for submitting code to pandas.
20
20
21
-
There is a tool in pandas to help contributors verify their changes before
22
-
contributing them to the project::
23
-
24
-
./ci/code_checks.sh
25
-
26
-
The script validates the doctests, formatting in docstrings, and
27
-
imported modules. It is possible to run the checks independently by using the
28
-
parameters ``docstrings``, ``code``, and ``doctests``
29
-
(e.g. ``./ci/code_checks.sh doctests``).
21
+
There are a couple of tools in pandas to help contributors verify their changes
22
+
before contributing to the project
23
+
- ``./ci/code_checks.sh``: a script validates the doctests, formatting in docstrings,
24
+
and imported modules. It is possible to run the checks independently by using the
25
+
parameters ``docstrings``, ``code``, and ``doctests``
26
+
(e.g. ``./ci/code_checks.sh doctests``);
27
+
- ``pre-commit``, which we go into detail on in the next section.
30
28
31
29
In addition, because a lot of people use our library, it is important that we
32
30
do not make sudden changes to the code that could have the potential to break
33
31
a lot of user code as a result, that is, we need it to be as *backwards compatible*
34
32
as possible to avoid mass breakages.
35
33
36
-
In addition to ``./ci/code_checks.sh``, some extra checks (including static type
37
-
checking) are run by ``pre-commit`` - see :ref:`here <contributing.pre-commit>`
38
-
for how to run them.
39
-
40
34
.. _contributing.pre-commit:
41
35
42
36
Pre-commit
43
37
----------
44
38
45
39
Additionally, :ref:`Continuous Integration <contributing.ci>` will run code formatting checks
46
40
like ``black``, ``ruff``,
47
-
``isort``, and ``cpplint`` and more using `pre-commit hooks <https://pre-commit.com/>`_
41
+
``isort``, and ``cpplint`` and more using `pre-commit hooks <https://pre-commit.com/>`_.
48
42
Any warnings from these checks will cause the :ref:`Continuous Integration <contributing.ci>` to fail; therefore,
49
43
it is helpful to run the check yourself before submitting code. This
50
-
can be done by installing ``pre-commit``::
51
-
52
-
pip install pre-commit
53
-
54
-
and then running::
44
+
can be done by installing ``pre-commit`` (which should already have happened if you followed the instructions
45
+
in :ref:`Setting up your development environment <contributing_environment>`) and then running::
55
46
56
47
pre-commit install
57
48
@@ -63,17 +54,17 @@ remain up-to-date with our code checks as they change.
63
54
Note that if needed, you can skip these checks with ``git commit --no-verify``.
64
55
65
56
If you don't want to use ``pre-commit`` as part of your workflow, you can still use it
66
-
to run its checks with::
57
+
to run its checks with one of the following::
67
58
68
59
pre-commit run --files <files you have modified>
60
+
pre-commit run --from-ref=upstream/main --to-ref=HEAD --all-files
69
61
70
62
without needing to have done ``pre-commit install`` beforehand.
71
63
72
-
If you want to run checks on all recently committed files on upstream/main you can use::
73
-
74
-
pre-commit run --from-ref=upstream/main --to-ref=HEAD --all-files
64
+
Finally, we also have some slow pre-commit checks, which don't run on each commit
65
+
but which do run during continuous integration. You can trigger them manually with
75
66
76
-
without needing to have done ``pre-commit install`` beforehand.
67
+
pre-commit run --hook-stage manual --all-files
77
68
78
69
.. note::
79
70
@@ -170,43 +161,9 @@ pandas strongly encourages the use of :pep:`484` style type hints. New developme
170
161
Style guidelines
171
162
~~~~~~~~~~~~~~~~
172
163
173
-
Type imports should follow the ``from typing import ...`` convention. Some types do not need to be imported since :pep:`585` some builtin constructs, such as ``list`` and ``tuple``, can directly be used for type annotations. So rather than
174
-
175
-
.. code-block:: python
176
-
177
-
import typing
178
-
179
-
primes: typing.List[int] = []
180
-
181
-
You should write
182
-
183
-
.. code-block:: python
184
-
185
-
primes: list[int] = []
186
-
187
-
``Optional`` should be avoided in favor of the shorter ``| None``, so instead of
188
-
189
-
.. code-block:: python
190
-
191
-
from typing import Union
192
-
193
-
maybe_primes: list[Union[int, None]] = []
194
-
195
-
or
196
-
197
-
.. code-block:: python
198
-
199
-
from typing import Optional
200
-
201
-
maybe_primes: list[Optional[int]] = []
202
-
203
-
You should write
204
-
205
-
.. code-block:: python
206
-
207
-
from__future__import annotations # noqa: F404
208
-
209
-
maybe_primes: list[int|None] = []
164
+
Type imports should follow the ``from typing import ...`` convention.
165
+
Your code may be automatically re-written to use some modern constructs (e.g. using the built-in ``list`` instead of ``typing.List``)
166
+
by the :ref:`pre-commit checks <contributing.pre-commit>`.
210
167
211
168
In some cases in the code base classes may define class variables that shadow builtins. This causes an issue as described in `Mypy 1775 <https://github.com/python/mypy/issues/1775#issuecomment-310969854>`_. The defensive solution here is to create an unambiguous alias of the builtin and use that without your annotation. For example, if you come across a definition like
0 commit comments