fixed a couple typos.

Author: PythonCHB

source/exercises/mailroom/mailroom_with_tests.rst

@@ -19,7 +19,11 @@ Guidelines
 
 Here are some suggestions on what should be refactored in your mailroom code.
 
-As mentioned above, testing user interaction code (code with ``print`` and ``input`` functions) is harder than testing the rest of your code. Testing user interaction code requires more advanced unit testing methodologies that will be revisited in future courses. Therefore, you should refactor your code so that the user interaction code contains as little business logic as possible. It should only interact with the user either by asking them for input or by responding to their request to print out data. Separating business logic from user interaction code is a good practice in general and we will come back to this concept in later lessons.
+As mentioned above, testing user interaction code (code with ``print`` and ``input`` functions) is harder than testing the rest of your code.
+Testing user interaction code requires more advanced unit testing methodologies that will be revisited in future courses.
+Therefore, you should refactor your code so that the user interaction code contains as little business logic as possible.
+It should only interact with the user either by asking them for input or by responding to their request to print out data.
+Separating business logic from user interaction code is a good practice in general and we will come back to this concept in later lessons.
 
 The refactoring in this lesson will allow you to unit test the functions with business logic, even if you don't test the user interaction code.
 
@@ -68,7 +72,9 @@ Send Letters
 ............
 
 This function should require very little or no change to make it unit-testable.
-To make it testable, you'll need to follow the same "separation of concerns" approach: the code that creates the letters should be separate from the code that prints them to the screen. This both allows you to test the letter creation, and leaves the door open to do something else with the letters: save to to a file, send as an email, etc. So the code that makes a letter likley will return a string with the entire letter contents.
+To make it testable, you'll need to follow the same "separation of concerns" approach: the code that creates the letters should be separate from the code that prints them to the screen.
+This both allows you to test the letter creation, and leaves the door open to do something else with the letters: save to to a file, send as an email, etc.
+So the code that makes a letter likely will return a string with the entire letter contents.
 
 For example:
 
@@ -83,15 +89,15 @@ For example:
         expected = "Frank, thanks a lot!"
         assert get_letter_text("Frank") == expected
 
-Note that some thought should go into the test of the letter. IF it's really simple, then checking comparing to a full letter is OK. But it might be better to test the important parts of the letter: Does it contain the correct name? does it contain the right amounts of money? rather than the entire text.
+Note that some thought should go into the test of the letter. If it's really simple, then simiply comparing to a full letter is OK. But it might be better to test the important parts of the letter: Does it contain the correct name? does it contain the right amounts of money? rather than the entire text.
 
 When you are done, every function in mailroom that does not contain a ``print`` or ``input`` call should be tested.
 
 And, critically: every function that contains a ``print`` or ``input`` should contain *no other logic at all*.
 
 Yes, that does mean that that you'll have some very simple functions like:
 
-..code-block:: python
+.. code-block:: python
 
 def print_letter(donor):
     print(make_letter(donor))

source/exercises/string_formatting.rst

@@ -10,21 +10,24 @@ In this exercise we will reinforce the important concepts of string formatting,
 
 Procedure
 =========
-Create a new file called ``strformat_lab.py`` in the exercise repo.
+Create a new file called ``string_formatting.py`` in the exercise repo -- or use the one that's there, if there is one.
 
 When the empty script is available and runnable, complete the following four tasks.
 
 
 Task One
 --------
-* Write a format string that will take the following four element tuple:
+* Write a format string that will take the following four values:
 
-    ``( 2, 123.4567, 10000, 12345.67)``
+    ``(2, 123.4567, 10000, 12345.67)``
 
     and produce:
 
     ``'file_002 :   123.46, 1.00e+04, 1.23e+04'``
 
+It should look like:
+
+  ``print("some_stuff_in_here".format(2, 123.4567, 10000, 12345.67))``
 
 Let's look at each of the four tuple elements in turn:
 
@@ -61,7 +64,7 @@ So you need to find a string formatting operator that will "pad" the number with
 Task Two
 --------
 
-Using your results from Task One, repeat the exercise, but this time using an alternate type of format string (hint: think about alternative ways to use .format() (keywords anyone?), and also consider f-strings if you've not used them already).
+Using your results from Task One, repeat the exercise, but this time use an alternate type of format string (hint: think about alternative ways to use .format() (keywords anyone?, or indexes?), and also consider f-strings if you've not used them already).
 
 
 Task Three
@@ -87,7 +90,7 @@ Hint: You can pass in a tuple of values to a function with a ``*``:
 
 The idea here is that you may have a tuple of three numbers, but might also have 4 or 5 or 2 or....
 
-so you can dynamically build up the format string to accommodate the length of the tuple.
+So you can dynamically build up the format string to accommodate the length of the tuple.
 
 The string object has the ``format()`` method, so you can call it with a string that is bound to a name, not just a string literal. For example:
 
@@ -187,7 +190,7 @@ or
 
 
 Task Six
----------
+--------
 Often it's convenient to display data in columns. String formatting helps to make this straightforward.
 
 Suppose you'd like to display something like:
@@ -206,7 +209,7 @@ Then you will need to use alignment specifiers. Do some research on this using t
 
 * Write some Python code to print a table of several rows, each with a name, an age and a cost. Make sure some of the costs are in the hundreds and thousands to test your alignment specifiers.
 
-* And for an extra task, given a tuple with 10 consecutive numbers, can you work how to quickly print the tuple in columns that are 5 charaters wide? It can be done on one short line!
+* And for an extra task, given a tuple with 10 consecutive numbers, can you work how to quickly print the tuple in columns that are 5 characters wide? It can be done on one short line!
 
 
 Resources on string formatting
@@ -227,10 +230,11 @@ https://mkaz.blog/code/python-string-format-cookbook/
 
 Submitting Your Work
 ====================
-Put the file in your student directory in a new subdirectory named for this lesson, and add it to your clone early.
+
+Add the file to the develop brnach of your repo for this excercise.
 
 Make frequent commits with good, clear messages about what you're doing and why.
 
-When you're done and ready for the instructors to review your work, push your changes to your gitHub fork and then go to the gitHub website and make a pull request.
+When you're done and ready for the instructors to review your work, push your changes to gitHub fork and then go to the gitHub website and make a pull request.
 
-Copy the gitHub link to the pull request, and use the +Submit Assignment link located in the top right corner to submit the URL here.
+Copy the gitHub link to the pull request, and provide it to the insstructors when you submit it in your LMS.

source/exercises/unit_testing/test_walnut_party.py

@@ -21,45 +21,33 @@
 # from walnut_party import walnut_party3 as walnut_party
 
 
-def test_1():
-    assert walnut_party(30, False) is False
+def test_too_few():
+    assert not walnut_party(30, False)
 
 
-def test_2():
-    assert walnut_party(50, False) is True
+def test_middle():
+    assert walnut_party(50, False)
 
 
-def test_3():
-    assert walnut_party(70, True) is True
+def test_too_many():
+    assert walnut_party(70, True)
 
 
-def test_4():
-    assert walnut_party(30, True) is False
+def test_middle50():
+    assert walnut_party(50, True)
 
 
-def test_5():
-    assert walnut_party(50, True) is True
+def test_upper_bound():
+    assert walnut_party(60, False)
 
 
-def test_6():
-    assert walnut_party(60, False) is True
+def test_just_too_big():
+    assert not walnut_party(61, False)
 
 
-def test_7():
-    assert walnut_party(61, False) is False
+def test_lower_bound():
+    assert walnut_party(40, False)
 
 
-def test_8():
-    assert walnut_party(40, False) is True
-
-
-def test_9():
+def test_just_too_small():
     assert walnut_party(39, False) is False
-
-
-def test_10():
-    assert walnut_party(40, True) is True
-
-
-def test_11():
-    assert walnut_party(39, True) is False