diff --git a/notes-python/contracts.md b/notes-python/contracts.md
index bd99c8a..2c1030a 100644
--- a/notes-python/contracts.md
+++ b/notes-python/contracts.md
@@ -11,7 +11,7 @@ def cat(left, right):
## Tests
-How can we be sure this code works? No, it's not obvious. Remember rules of the game, we have an incredibly complicated realization. So, we can't say it works or not while we haven't tested it.
+How can we be sure this code works? No, it's not obvious. Remember the rules of the game, we have an incredibly complicated realization. So, we can't say it works or not while we haven't tested it.
```python
def test_cat():
@@ -49,13 +49,13 @@ def test_cat(left, right, expected):
## Properties
-Table tests can be enormously long, and for every test case we have to manually calculate expected result. For complicated code it's a lot of work. Can we do it better and think and write less? Yes, we can instead of _expected result_ talk about _expected properties of the result_. The big difference is the result is different for different input values, but properties always the same. The coolest thing is in most cases you already know result properties, it is the business requirements, and your code is no more than implementation of these requirements.
+Table tests can be enormously long, and for every test case, we have to manually calculate the expected result. For complicated code, it's a lot of work. Can we do it better and think and write less? Yes, we can instead of _expected result_ talk about _expected properties of the result_. The big difference is the result is different for different input values, but properties always the same. The coolest thing is in most cases you already know result properties, it is the business requirements, and your code is no more than the implementation of these requirements.
So, what are the properties of our function?
-1. Result string starts with the first given string.
-1. Result string ends with the second given string.
-1. Result string has the length equal to sum of lengths of given strings.
+1. The result string starts with the first given string.
+1. The result string ends with the second given string.
+1. Result string has the length equal to the sum of lengths of given strings.
Now, we can check these properties for the result instead of checking particular values.
@@ -76,7 +76,7 @@ def test_cat(left, right):
## Hypothesis
-We've tested a few corner cases but not all of them. What about unicode strings? What if one string is unicode, but another one isn't? What about spaces? What if we have string termination symbol somewhere? What if both strings contain only digits (place where JS always surprises)? It's so hard to find examples for all possible cases where something can go wrong. In theory, you even can't say that it works while you haven't checked **all** possible values (that impossible even for our simple function). So, instead of trying to figure out all possible nightly values we can ask machine to do so. This is where the [property-based testing](https://dev.to/jdsteinhauser/intro-to-property-based-testing-2cj8) comes in. In Python, we have a great tool [hypothesis](https://hypothesis.readthedocs.io/en/latest/) that can generate test examples for us:
+We've tested a few corner cases but not all of them. What about Unicode strings? What if one string is Unicode, but another one isn't? What about spaces? What if we have a string termination symbol somewhere? What if both strings contain only digits (the place where JS always surprises)? It's so hard to find examples for all possible cases where something can go wrong. In theory, you even can't say that it works while you haven't checked **all** possible values (that impossible even for our simple function). So, instead of trying to figure out all possible nightly values we can ask the machine to do so. This is where the [property-based testing](https://dev.to/jdsteinhauser/intro-to-property-based-testing-2cj8) comes in. In Python, we have a great tool [hypothesis](https://hypothesis.readthedocs.io/en/latest/) that can generate test examples for us:
```python
import hypothesis
@@ -99,7 +99,7 @@ def cat(left: str, right: str) -> str:
return left + right
```
-Type annotations aren't perfect and can be too complicated. However what is most important is now humans and machines know much more about your code. You can run [mypy](https://github.com/python/mypy) and check that you haven't made type errors. And the thing is it's not only about catching type errors. Now we can use [hypothesis-auto](https://timothycrosley.github.io/hypothesis-auto/) wrapper around hypothesis. It will infer parameters types and explain names and types of parameters to Hypothesis. So, instead of writing `hypothesis.given(left=strategies.text(), right=strategies.text())` we can just say `hypothesis_auto.auto_pytest(cat)`.
+Type annotations aren't perfect and can be too complicated. However, what is most important is now humans and machines know much more about your code. You can run [mypy](https://github.com/python/mypy) and check that you haven't made type errors. And the thing is it's not only about catching type errors. Now we can use [hypothesis-auto](https://timothycrosley.github.io/hypothesis-auto/) wrapper around hypothesis. It will infer parameters types and explain names and types of parameters to Hypothesis. So, instead of writing `hypothesis.given(left=strategies.text(), right=strategies.text())` we can just say `hypothesis_auto.auto_pytest(cat)`.
```python
import hypothesis_auto
@@ -118,9 +118,9 @@ It looks longer because now parameters are placed inside the long name `test_cas
## Contracts
-Can we make it even simpler? Not really. The implementation can produce some values, and the machine can infer some properties of the result. However, someone else must say which properties are good and expected, and which are not. However, there is something else about our properties that we can do better. At this stage we have type annotations and, to be honest, they are just kind of properties. Annotations say "the result is a text", and our test properties clarifies the length of the result, it's prefix and suffix. However, the difference is type annotations are the part of the function itself. It gives some benefits:
+Can we make it even simpler? Not really. The implementation can produce some values, and the machine can infer some properties of the result. However, someone else must say which properties are good and expected, and which are not. However, there is something else about our properties that we can do better. At this stage we have type annotations and, to be honest, they are just kind of properties. Annotations say "the result is a text", and our test properties clarify the length of the result, it's prefix and suffix. However, the difference is type annotations are the part of the function itself. It gives some benefits:
-1. The machine can check statically, without actual running of the code.
+1. The machine can check statically, without the actual running of the code.
1. The human can see types (think "possible values set") for arguments and the result.
Package [deal](https://github.com/life4/deal) is the thing that can make the same for our properties.
@@ -135,7 +135,7 @@ def cat(left: str, right: str) -> str:
return left + right
```
-How, it's not just properties, but [contracts](https://en.wikipedia.org/wiki/Design_by_contract). They can be checked in the runtime, simplify tests, tell humans about the function behavior. And tests for this implementation are incredibly trivial:
+Now, it's not just properties, but [contracts](https://en.wikipedia.org/wiki/Design_by_contract). They can be checked in the runtime, simplify tests, tell humans about the function behavior. And tests for this implementation are incredibly trivial:
```python
@pytest.mark.parametrize('case', deal.cases(cat))
@@ -155,7 +155,7 @@ def sin(x):
return 2
```
-And wheh we run [deal linter](https://deal.readthedocs.io/linter.html) on this code, we see contract violation error:
+And when we run [deal linter](https://deal.readthedocs.io/linter.html) on this code, we see contract violation error:
```bash
❯ flake8 --show-source sin.py