Random grammar stuff (#2955)
diff --git a/docs/development/getting-started.rst b/docs/development/getting-started.rst
index 0bbb18c..3ad9fe8 100644
--- a/docs/development/getting-started.rst
+++ b/docs/development/getting-started.rst
@@ -27,7 +27,7 @@
``CFLAGS`` and ``LDFLAGS`` environment variables before installing the
``dev-requirements.txt`` otherwise pip will fail with include errors.
-For example with `Homebrew`_:
+For example, with `Homebrew`_:
.. code-block:: console
diff --git a/docs/development/submitting-patches.rst b/docs/development/submitting-patches.rst
index 563bc81..475e703 100644
--- a/docs/development/submitting-patches.rst
+++ b/docs/development/submitting-patches.rst
@@ -48,7 +48,7 @@
Most projects' APIs are designed with a philosophy of "make easy things easy,
and make hard things possible". One of the perils of writing cryptographic code
is that secure code looks just like insecure code, and its results are almost
-always indistinguishable. As a result ``cryptography`` has, as a design
+always indistinguishable. As a result, ``cryptography`` has, as a design
philosophy: "make it hard to do insecure things". Here are a few strategies for
API design that should be both followed, and should inspire other API choices:
diff --git a/src/cryptography/hazmat/backends/openssl/rsa.py b/src/cryptography/hazmat/backends/openssl/rsa.py
index 1d86bfe..d8458cc 100644
--- a/src/cryptography/hazmat/backends/openssl/rsa.py
+++ b/src/cryptography/hazmat/backends/openssl/rsa.py
@@ -141,7 +141,7 @@
backend._lib.RSA_R_OAEP_DECODING_ERROR,
# Though this error looks similar to the
# RSA_R_DATA_TOO_LARGE_FOR_KEY_SIZE, this occurs on decrypts,
- # rather then on encrypts
+ # rather than on encrypts
backend._lib.RSA_R_DATA_TOO_LARGE_FOR_MODULUS,
]
if backend._lib.Cryptography_HAS_RSA_R_PKCS_DECODING_ERROR:
diff --git a/tests/hazmat/primitives/test_rsa.py b/tests/hazmat/primitives/test_rsa.py
index 2331a93..6a8bb95 100644
--- a/tests/hazmat/primitives/test_rsa.py
+++ b/tests/hazmat/primitives/test_rsa.py
@@ -1845,7 +1845,7 @@
)
# Unfortunately there is no convention on which prime should be p
# and which one q. The function we use always makes p < q, but the
- # NIST vectors are not so consistent. Accordingly we verify we've
+ # NIST vectors are not so consistent. Accordingly, we verify we've
# recovered the proper (p, q) by sorting them and asserting on that.
assert sorted([p, q]) == sorted([private["p"], private["q"]])