aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorAlex Gaynor <alex.gaynor@gmail.com>2015-09-24 22:07:13 -0400
committerAlex Gaynor <alex.gaynor@gmail.com>2015-09-24 22:07:13 -0400
commitc79a81cb579551136e80d63a3479f619e2064618 (patch)
tree7d13c85da2bb1e5058b36ef2490678cf387fcda1
parent16b67fce20f79ce326194e88156bd3e734730362 (diff)
downloadcryptography-c79a81cb579551136e80d63a3479f619e2064618.tar.gz
cryptography-c79a81cb579551136e80d63a3479f619e2064618.tar.bz2
cryptography-c79a81cb579551136e80d63a3479f619e2064618.zip
appeasement
-rw-r--r--docs/development/submitting-patches.rst2
1 files changed, 1 insertions, 1 deletions
diff --git a/docs/development/submitting-patches.rst b/docs/development/submitting-patches.rst
index 33cde101..66105843 100644
--- a/docs/development/submitting-patches.rst
+++ b/docs/development/submitting-patches.rst
@@ -48,7 +48,7 @@ API considerations
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: