Add style checking with pre-commit + black, and a CI job (#684)

Signed-off-by: nstarman <[email protected]>

Author: nstarman

.git-blame-ignore-revs

@@ -4,4 +4,4 @@
 # Move special cases to notes sections
 816fba3b75c38cbb1bb6fe5b1342adc5eab694f3
 0a2fa71a32b924cc92718db29910a6cbbc5e9341
-931144e7d7d5c8b23393aa730ef28962a35b113b
+931144e7d7d5c8b23393aa730ef28962a35b113b

.github/workflows/ci.yml

@@ -0,0 +1,46 @@
+#/
+# @license MIT
+#
+# Copyright (c) 2022 Python Data APIs Consortium.
+#
+# Permission is hereby granted, free of charge, to any person obtaining a copy
+# of this software and associated documentation files (the "Software"), to deal
+# in the Software without restriction, including without limitation the rights
+# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+# copies of the Software, and to permit persons to whom the Software is
+# furnished to do so, subject to the following conditions:
+#
+# The above copyright notice and this permission notice shall be included in all
+# copies or substantial portions of the Software.
+#
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+# SOFTWARE.
+#/
+
+# Workflow name:
+name: ci
+
+# Workflow triggers:
+on:
+  pull_request:
+  push:
+    branches: [main,]
+
+# Workflow jobs:
+jobs:
+
+  main:
+    runs-on: ubuntu-latest
+    steps:
+    - uses: actions/checkout@v3
+    - uses: actions/setup-python@v4
+      with:
+        python-version: 3.8
+    - uses: pre-commit/[email protected]
+    - uses: pre-commit-ci/[email protected]
+      if: always()

.github/workflows/pages.yml

@@ -45,10 +45,10 @@ jobs:
 
     # Avoid running this workflow for forks and allow skipping CI:
     if: "github.repository == 'data-apis/array-api' && !contains(github.event.head_commit.message, '[ci skip]') && !contains(github.event.head_commit.message, '[skip ci]') && !contains(github.event.head_commit.message, '[skip github]')"
-    
+
     # Define a sequence of job steps...
     steps:
-      
+
       # Checkout the repository:
       - name: 'Checkout repository'
         uses: actions/checkout@v2

.pre-commit-config.yaml

@@ -0,0 +1,50 @@
+repos:
+  - repo: https://github.com/pre-commit/pre-commit-hooks
+    rev: v4.4.0
+    hooks:
+      - id: check-added-large-files
+        # Prevent giant files from being committed.
+      - id: check-ast
+        # Simply check whether files parse as valid python.
+      - id: check-case-conflict
+        # Check for files with names that would conflict on a case-insensitive
+        # filesystem like MacOS HFS+ or Windows FAT.
+      - id: check-json
+        # Attempts to load all json files to verify syntax.
+      - id: check-merge-conflict
+        # Check for files that contain merge conflict strings.
+      - id: check-symlinks
+        # Checks for symlinks which do not point to anything.
+      - id: check-toml
+        # Attempts to load all TOML files to verify syntax.
+      - id: check-xml
+        # Attempts to load all xml files to verify syntax.
+      - id: check-yaml
+        # Attempts to load all yaml files to verify syntax.
+        exclude: ".*(.github.*)$"
+      - id: debug-statements
+        # Check for debugger imports and py37+ breakpoint() calls in python
+        # source.
+      - id: detect-private-key
+        # Checks for the existence of private keys.
+      - id: end-of-file-fixer
+        # Makes sure files end in a newline and only a newline.
+      - id: trailing-whitespace
+        # Trims trailing whitespace.
+        exclude_types: [python]
+
+  - repo: https://github.com/pre-commit/pygrep-hooks
+    rev: v1.10.0
+    hooks:
+      - id: python-check-mock-methods
+        # Prevent common mistakes of assert mck.not_called(), assert
+        # mck.called_once_with(...) and mck.assert_called.
+      - id: text-unicode-replacement-char
+        # Forbid files which have a UTF-8 Unicode replacement character.
+      - id: python-check-blanket-noqa
+        # Enforce that all noqa annotations always occur with specific codes.
+
+  - repo: https://github.com/psf/black-pre-commit-mirror
+    rev: 23.7.0
+    hooks:
+      - id: black

CHANGELOG.md

@@ -196,4 +196,4 @@ The following is a list of fixes and points of clarification with regard to the
 - `linspace`: conversion of `start` and `stop` should follow type promotion rules ([gh-568](https://github.com/data-apis/array-api/pull/568))
 - `nonzero`: clarify that, for arrays having a boolean data type, non-zero elements are those elements which equal `True` ([gh-441](https://github.com/data-apis/array-api/pull/441))
 - `trunc`: fix description ([gh-511](https://github.com/data-apis/array-api/pull/511))
-- `vecdot`: clarify broadcasting behavior ([gh-417](https://github.com/data-apis/array-api/pull/417) and [gh-473](https://github.com/data-apis/array-api/pull/473))
+- `vecdot`: clarify broadcasting behavior ([gh-417](https://github.com/data-apis/array-api/pull/417) and [gh-473](https://github.com/data-apis/array-api/pull/473))

CODE_OF_CONDUCT.md

@@ -1,3 +1,3 @@
 Please note that the Consortium for Python Data API Standards has a Code of
 Conduct that we ask everyone to respect, see:
-https://github.com/data-apis/.github/blob/master/CODE_OF_CONDUCT.md
+https://github.com/data-apis/.github/blob/master/CODE_OF_CONDUCT.md

README.md

@@ -244,4 +244,4 @@ Thanks goes to these wonderful people ([emoji key](https://allcontributors.org/d
 
 <!-- ALL-CONTRIBUTORS-LIST:END -->
 
-This project follows the [all-contributors](https://github.com/all-contributors/all-contributors) specification. Contributions of any kind welcome!
+This project follows the [all-contributors](https://github.com/all-contributors/all-contributors) specification. Contributions of any kind welcome!

pyproject.toml

@@ -29,3 +29,6 @@ doc = [
 [build-system]
 requires = ["setuptools"]
 build-backend = "setuptools.build_meta"
+
+[tool.black]
+line-length = 88

spec/2021.12/benchmark_suite.md

@@ -1,3 +1,3 @@
 # Benchmark suite
 
-Adding a benchmark suite is planned in the future.
+Adding a benchmark suite is planned in the future.

spec/2021.12/conf.py

@@ -1,5 +1,6 @@
 import sys
 from pathlib import Path
+
 sys.path.insert(0, str(Path(__file__).parents[2] / "src"))
 
 from array_api_stubs import _2021_12 as stubs_mod

spec/2021.12/design_topics/accuracy.rst

@@ -74,4 +74,4 @@ This specification does not specify accuracy requirements for statistical functi
 Linear Algebra
 --------------
 
-This specification does not specify accuracy requirements for linear algebra functions; however, this specification does expect that a conforming implementation of the array API standard will make a best-effort attempt to ensure that its implementations are theoretically sound and numerically robust.
+This specification does not specify accuracy requirements for linear algebra functions; however, this specification does expect that a conforming implementation of the array API standard will make a best-effort attempt to ensure that its implementations are theoretically sound and numerically robust.

spec/2021.12/design_topics/parallelism.rst

@@ -21,4 +21,4 @@ coordination of parallelization behavior in a stack of Python libraries are:
 
 Option (1) may possibly fit in a future version of this array API standard.
 `array-api issue 4 <https://github.com/data-apis/array-api/issues/4>`_ contains
-more detailed discussion on the topic of parallelism.
+more detailed discussion on the topic of parallelism.

spec/2021.12/future_API_evolution.md

@@ -57,4 +57,4 @@ than Python package versioning.
 
 The frequency of releasing a new version of an API standard will likely be at
 regular intervals and on the order of one year, however no assumption on
-frequency of new versions appearing must be made.
+frequency of new versions appearing must be made.

spec/2021.12/usage_data.md

@@ -82,5 +82,5 @@ See the [`python-record-api`](https://github.com/data-apis/python-record-api) re
 Design and usage data support specification decision-making in the following ways.
 
 - Validate user stories to ensure that proposals satisfy existing needs.
-- Define scope to ensure that proposals address general array library design requirements (i.e., proposals must have broad applicability and be possible to implement with a reasonable amount of effort). 
-- Inform technical design discussions to ensure that proposals are grounded in empirical data.
+- Define scope to ensure that proposals address general array library design requirements (i.e., proposals must have broad applicability and be possible to implement with a reasonable amount of effort).
+- Inform technical design discussions to ensure that proposals are grounded in empirical data.

spec/2021.12/use_cases.md

@@ -232,4 +232,4 @@ def check(x, y):
     # (this is different from Numpy, whose behaviour depends on
     #  the *values* of the arguments -- see PyArray_CanCastArrayTo).
     self.assertEqual(got.dtype, x.dtype)
-```
+```

spec/2022.12/benchmark_suite.md

@@ -1,3 +1,3 @@
 # Benchmark suite
 
-Adding a benchmark suite is planned in the future.
+Adding a benchmark suite is planned in the future.

spec/2022.12/conf.py

@@ -1,5 +1,6 @@
 import sys
 from pathlib import Path
+
 sys.path.insert(0, str(Path(__file__).parents[2] / "src"))
 
 from array_api_stubs import _2022_12 as stubs_mod

spec/2022.12/design_topics/accuracy.rst

@@ -74,4 +74,4 @@ This specification does not specify accuracy requirements for statistical functi
 Linear Algebra
 --------------
 
-This specification does not specify accuracy requirements for linear algebra functions; however, this specification does expect that a conforming implementation of the array API standard will make a best-effort attempt to ensure that its implementations are theoretically sound and numerically robust.
+This specification does not specify accuracy requirements for linear algebra functions; however, this specification does expect that a conforming implementation of the array API standard will make a best-effort attempt to ensure that its implementations are theoretically sound and numerically robust.

spec/2022.12/design_topics/complex_numbers.rst

@@ -27,7 +27,7 @@ Branch cuts do not arise for single-valued trigonometric, hyperbolic, integer po
 In contrast to real-valued floating-point numbers which have well-defined behavior as specified in IEEE 754, complex-valued floating-point numbers have no equivalent specification. Accordingly, this specification chooses to follow C99 conventions for special cases and branch cuts for those functions supporting complex numbers. For those functions which do not have C99 equivalents (e.g., linear algebra APIs), the specification relies on dominant conventions among existing array libraries.
 
 .. warning::
-   All branch cuts documented in this specification are considered **provisional**. While conforming implementations of the array API standard should adopt the branch cuts described in this standard, consumers of array API standard implementations should **not** assume that branch cuts are consistent between implementations. 
+   All branch cuts documented in this specification are considered **provisional**. While conforming implementations of the array API standard should adopt the branch cuts described in this standard, consumers of array API standard implementations should **not** assume that branch cuts are consistent between implementations.
 
    Provided no issues arise due to the choice of branch cut, the provisional status is likely to be removed in a future revision of this standard.
 
@@ -58,4 +58,4 @@ Valued-based Promotion
 
 According to the type promotion rules described in this specification (see :ref:`type-promotion`), only the data types of the input arrays participating in an operation matter, not their values. The same principle applies to situations in which one or more results of operations on real-valued arrays are mathematically defined in the complex domain, but not in their real domain.
 
-By convention, the principal square root of :math:`-1` is :math:`j`, where :math:`j` is the imaginary unit. Despite this convention, for those operations supporting type promotion, conforming implementations must only consider input array data types when determining the data type of the output array. For example, if a real-valued input array is provided to :func:`~array_api.sqrt`, the output array must also be real-valued, even if the input array contains negative values. Accordingly, if a consumer of a conforming implementation of this specification desires for an operation's results to include the complex domain, the consumer should first cast the input array(s) to an appropriate complex floating-point data type before performing the operation.
+By convention, the principal square root of :math:`-1` is :math:`j`, where :math:`j` is the imaginary unit. Despite this convention, for those operations supporting type promotion, conforming implementations must only consider input array data types when determining the data type of the output array. For example, if a real-valued input array is provided to :func:`~array_api.sqrt`, the output array must also be real-valued, even if the input array contains negative values. Accordingly, if a consumer of a conforming implementation of this specification desires for an operation's results to include the complex domain, the consumer should first cast the input array(s) to an appropriate complex floating-point data type before performing the operation.

spec/2022.12/design_topics/parallelism.rst

@@ -21,4 +21,4 @@ coordination of parallelization behavior in a stack of Python libraries are:
 
 Option (1) may possibly fit in a future version of this array API standard.
 `array-api issue 4 <https://github.com/data-apis/array-api/issues/4>`_ contains
-more detailed discussion on the topic of parallelism.
+more detailed discussion on the topic of parallelism.

spec/2022.12/future_API_evolution.md

@@ -57,4 +57,4 @@ than Python package versioning.
 
 The frequency of releasing a new version of an API standard will likely be at
 regular intervals and on the order of one year, however no assumption on
-frequency of new versions appearing must be made.
+frequency of new versions appearing must be made.

spec/2022.12/usage_data.md

@@ -82,5 +82,5 @@ See the [`python-record-api`](https://github.com/data-apis/python-record-api) re
 Design and usage data support specification decision-making in the following ways.
 
 - Validate user stories to ensure that proposals satisfy existing needs.
-- Define scope to ensure that proposals address general array library design requirements (i.e., proposals must have broad applicability and be possible to implement with a reasonable amount of effort). 
-- Inform technical design discussions to ensure that proposals are grounded in empirical data.
+- Define scope to ensure that proposals address general array library design requirements (i.e., proposals must have broad applicability and be possible to implement with a reasonable amount of effort).
+- Inform technical design discussions to ensure that proposals are grounded in empirical data.

spec/2022.12/use_cases.md

@@ -232,4 +232,4 @@ def check(x, y):
     # (this is different from Numpy, whose behaviour depends on
     #  the *values* of the arguments -- see PyArray_CanCastArrayTo).
     self.assertEqual(got.dtype, x.dtype)
-```
+```

spec/_static/css/custom.css

@@ -1,3 +1,3 @@
 s {
     text-decoration: inherit;
-}
+}

spec/_templates/property.rst

@@ -2,4 +2,4 @@
 
 {{ name.split('.')[-1] | underline }}
 
-.. auto{{ objtype }}:: {{ objname }}
+.. auto{{ objtype }}:: {{ objname }}

spec/draft/benchmark_suite.md

@@ -1,3 +1,3 @@
 # Benchmark suite
 
-Adding a benchmark suite is planned in the future.
+Adding a benchmark suite is planned in the future.

spec/draft/conf.py

@@ -1,5 +1,6 @@
 import sys
 from pathlib import Path
+
 sys.path.insert(0, str(Path(__file__).parents[2] / "src"))
 
 from array_api_stubs import _draft as stubs_mod

spec/draft/design_topics/accuracy.rst

@@ -74,4 +74,4 @@ This specification does not specify accuracy requirements for statistical functi
 Linear Algebra
 --------------
 
-This specification does not specify accuracy requirements for linear algebra functions; however, this specification does expect that a conforming implementation of the array API standard will make a best-effort attempt to ensure that its implementations are theoretically sound and numerically robust.
+This specification does not specify accuracy requirements for linear algebra functions; however, this specification does expect that a conforming implementation of the array API standard will make a best-effort attempt to ensure that its implementations are theoretically sound and numerically robust.

spec/draft/design_topics/complex_numbers.rst

@@ -27,7 +27,7 @@ Branch cuts do not arise for single-valued trigonometric, hyperbolic, integer po
 In contrast to real-valued floating-point numbers which have well-defined behavior as specified in IEEE 754, complex-valued floating-point numbers have no equivalent specification. Accordingly, this specification chooses to follow C99 conventions for special cases and branch cuts for those functions supporting complex numbers. For those functions which do not have C99 equivalents (e.g., linear algebra APIs), the specification relies on dominant conventions among existing array libraries.
 
 .. warning::
-   All branch cuts documented in this specification are considered **provisional**. While conforming implementations of the array API standard should adopt the branch cuts described in this standard, consumers of array API standard implementations should **not** assume that branch cuts are consistent between implementations. 
+   All branch cuts documented in this specification are considered **provisional**. While conforming implementations of the array API standard should adopt the branch cuts described in this standard, consumers of array API standard implementations should **not** assume that branch cuts are consistent between implementations.
 
    Provided no issues arise due to the choice of branch cut, the provisional status is likely to be removed in a future revision of this standard.
 
@@ -58,4 +58,4 @@ Valued-based Promotion
 
 According to the type promotion rules described in this specification (see :ref:`type-promotion`), only the data types of the input arrays participating in an operation matter, not their values. The same principle applies to situations in which one or more results of operations on real-valued arrays are mathematically defined in the complex domain, but not in their real domain.
 
-By convention, the principal square root of :math:`-1` is :math:`j`, where :math:`j` is the imaginary unit. Despite this convention, for those operations supporting type promotion, conforming implementations must only consider input array data types when determining the data type of the output array. For example, if a real-valued input array is provided to :func:`~array_api.sqrt`, the output array must also be real-valued, even if the input array contains negative values. Accordingly, if a consumer of a conforming implementation of this specification desires for an operation's results to include the complex domain, the consumer should first cast the input array(s) to an appropriate complex floating-point data type before performing the operation.
+By convention, the principal square root of :math:`-1` is :math:`j`, where :math:`j` is the imaginary unit. Despite this convention, for those operations supporting type promotion, conforming implementations must only consider input array data types when determining the data type of the output array. For example, if a real-valued input array is provided to :func:`~array_api.sqrt`, the output array must also be real-valued, even if the input array contains negative values. Accordingly, if a consumer of a conforming implementation of this specification desires for an operation's results to include the complex domain, the consumer should first cast the input array(s) to an appropriate complex floating-point data type before performing the operation.