Merge pull request #99 from rpdelaney/spelling

Copyedits to docs

docs/basic/intro.md

@@ -43,7 +43,7 @@ It's not "advanced usage", there is nothing advanced or difficult. It's about wr
 
 1. {doc}`/details/contracts` gives you additional tools to reuse and simplify contracts.
 1. {doc}`/details/module_load` allow you to control what happens at the module load (import) time.
-1. {doc}`/details/dispatch` is a way to combine multiple implementations for a function into one based on pre-conditions.
+1. {doc}`/details/dispatch` is a way to combine multiple implementations for a function into one based on preconditions.
 1. {doc}`/details/docs` provides information on generating documentation for functions with contracts (using Sphinx).
 1. {doc}`/details/stubs` is a way to store some contracts in a JSON file instead of the source code. It can be helpful for third-party libraries. Some stubs already inside Deal.
 1. {doc}`/details/tests` provides information on finding memory leaks and tweaking tests generation.

docs/basic/linter.md

@@ -4,7 +4,7 @@ Deal can do static checks for functions with contracts to catch trivial mistakes
 
 ## flake8
 
-Most probably, you already use [flake8](http://flake8.pycqa.org), so this option should suit best for you. Deal has built-in flake8 plugin which will be autimatically discovered if you install flake8 and deal in the same environment.
+Most probably, you already use [flake8](http://flake8.pycqa.org), so this option should suit best for you. Deal has built-in flake8 plugin which will be automatically discovered if you install flake8 and deal in the same environment.
 
 ```bash
 python3 -m pip install --user flake8 deal

docs/basic/side-effects.md

@@ -74,7 +74,7 @@ Other markers aren't checked in runtime yet but only checked by the [linter](lin
 
 ## Markers are properties
 
-Markers and exceptions are properties of a function and don't depend on conditions. That means, if a function only sometimes in some conditions does io operation, the function has `io` marker regardless of possibility of hitting this condition branch. For example:
+Markers and exceptions are properties of a function and don't depend on conditions. That means if a function only sometimes in some conditions does io operation, the function has `io` marker regardless of possibility of hitting this condition branch. For example:
 
 ```python run
 import deal
@@ -91,4 +91,4 @@ def main():
     return 0
 ```
 
-If we run [linter](linter) on the code above, it will fail with "DEAL046 missed marker (stdout)" message. `main` function calls `run_job` with `silent=True` so `print` will not be called when calling `main`. However, `run_job` function has an implicit `stdout` marker, and `main` calls this function so it must have this marker as well.
+If we run [linter](linter) on the code above, it will fail with "DEAL046 missed marker (stdout)" message. `main` function calls `run_job` with `silent=True`, so `print` will not be called when calling `main`. However, `run_job` function has an implicit `stdout` marker, and `main` calls this function so it must have this marker as well.

docs/basic/tests.md

@@ -4,7 +4,7 @@ Deal can automatically test your functions. First of all, your function has to b
 
 1. All function arguments are type-annotated.
 1. All exceptions that function can raise are specified in {py:func}`deal.raises`.
-1. All pre-conditions are specified with {py:func}`deal.pre`.
+1. All preconditions are specified with {py:func}`deal.pre`.
 
 ```python run
 @deal.raises(ZeroDivisionError)

docs/basic/verification.md

@@ -17,7 +17,7 @@ Prerequisites for code to be verified:
 + It is a function or `@staticmethod`.
 + It is written on pure Python and calls only pure Python code.
 + Every argument is type annotated.
-+ Even if everything above is satisfied, the functon still can be skipped because a feature it uses is not supported yet.
++ Even if everything above is satisfied, the function still can be skipped because a feature it uses is not supported yet.
 
 Below, we use the following terms:
 

docs/details/dispatch.md

@@ -25,7 +25,7 @@ age2stage(10)  # 'kid'
 age2stage(14)  # 'teen'
 ```
 
-If the given arguments passed pre-conditions for none of the implementations, `NoMatchError` is raised:
+If the given arguments passed preconditions for none of the implementations, `NoMatchError` is raised:
 
 ```python
 age2stage(20)
@@ -48,7 +48,7 @@ Since dispatch requires contracts to be enabled, when you call a dispatched func
 
 ## Motivation
 
-The decorator was introduced as a way to do the same as [functools.singledispatch] but using pre-conditions instead of types. It gives you much more flexibility, allowing you to implement anything you could do in some other languages with the combination of [pattern matching], [guards], and [function overloading]. A classic example is recursively calculating factorial.
+The decorator was introduced as a way to do the same as [functools.singledispatch] but using preconditions instead of types. It gives you much more flexibility, allowing you to implement anything you could do in some other languages with the combination of [pattern matching], [guards], and [function overloading]. A classic example is recursively calculating factorial.
 
 In Elixir:
 

docs/details/tests.md

@@ -27,7 +27,7 @@ The command `memtest` uses this idea to find memory leaks in pure functions. How
     1. It makes memory snapshot before running the function.
     1. It runs the function with different autogenerated input arguments (as `test` command does) without running contracts and checking the return value type (to avoid side-effects from deal itself).
     1. It makes memory snapshot after running the function.
-    1. Snapshots "before" and "after" are comapared. If there is a difference it will be printed.
+    1. Snapshots "before" and "after" are compared. If there is a difference it will be printed.
 
 The return code is equal to the amount of functions with memory leaks.
 
@@ -76,7 +76,7 @@ for case in cases:
 
 Argument `seed` of `deal.cases` is a random seed. That means, for the same seed value you always get the same test cases. It is a must-have thing for CI. There are a few important things:
 
-+ If the seed is different for diferrent pipelines, it will run a bit different test cases every time which increases your chances to find a tricky corner case.
++ If the seed is different for different pipelines, it will run a bit different test cases every time which increases your chances to find a tricky corner case.
 + If the seed is the same when you re-run the same job, it will help you to identify flaky tests. In other words, if a CI job fails, you re-run it, and it passes, it was a flaky test which happens because of tricky side-effects (database connection failed, another test changed a state etc.) and it will be hard to reproduce. However, if re-run fails with the same error, most probably it is a failure that you can easily reproduce and debug locally, knowing the seed.
 + The seed should be shown in the CI job to make it possible to use it locally to reproduce a failure. It is either printed in the job output or is something known like the pipeline run number.