fix long lines as described in swcarpentry#498

CONTRIBUTING.md

@@ -111,7 +111,8 @@ To use the web interface for contributing to a lesson:
 1.  Fork the originating repository to your GitHub profile.
 2.  Within your version of the forked repository, move to the `gh-pages` branch and
 create a new branch for each significant change being made.
-3.  Navigate to the file(s) you wish to change within the new branches and make revisions as required.
+3.  Navigate to the file(s) you wish to change within the new branches and 
+make revisions as required.
 4.  Commit all changed files within the appropriate branches.
 5.  Create individual pull requests from each of your changed branches
 to the `gh-pages` branch within the originating repository.
@@ -123,7 +124,8 @@ When starting work, please make sure your clone of the originating `gh-pages` br
 before creating your own revision-specific branch(es) from there.
 Additionally, please only work from your newly-created branch(es) and *not*
 your clone of the originating `gh-pages` branch.
-Lastly, published copies of all the lessons are available in the `gh-pages` branch of the originating
+Lastly, published copies of all the lessons are available 
+in the `gh-pages` branch of the originating
 repository for reference while revising.
 
 ## Other Resources

README.md

@@ -8,9 +8,16 @@ An introduction to Python for non-programmers using inflammation data.
 
 ## About the Lesson
 
-This lesson teaches novice programmers to write modular code to perform data analysis using Python. The emphasis, however, is on teaching language-agnostic principles of programming such as automation with loops and encapsulation with functions, see [Best Practices for Scientific Computing][best-practices] and [Good enough practices in scientific computing][good-enough-practices] to learn more.
-
-The example used in this lesson analyses a set of 12 files with simulated inflammation data collected from a trial for a new treatment for arthritis. Learners are shown how it is better to automate analysis using functions instead of repeating analysis steps manually.
+This lesson teaches novice programmers to write modular code to perform data analysis 
+using Python. The emphasis, however, is on teaching language-agnostic principles of 
+programming such as automation with loops and encapsulation with functions, 
+see [Best Practices for Scientific Computing][best-practices] and 
+[Good enough practices in scientific computing][good-enough-practices] to learn more.
+
+The example used in this lesson analyses a set of 12 files with simulated inflammation 
+data collected from a trial for a new treatment for arthritis. Learners are shown 
+how it is better to automate analysis using functions instead of repeating analysis 
+steps manually.
 
 The rendered version of the lesson: <https://swcarpentry.github.io/python-novice-inflammation/>
 

_episodes/07-errors.md

@@ -77,13 +77,15 @@ In this case:
 
 The last level is the actual place where the error occurred.
 The other level(s) show what function the program executed to get to the next level down.
-So, in this case, the program first performed a [function call]({{ page.root }}/reference/#function-call) to the function `favorite_ice_cream`.
+So, in this case, the program first performed a 
+[function call]({{ page.root }}/reference/#function-call) to the function `favorite_ice_cream`.
 Inside this function,
 the program encountered an error on Line 6, when it tried to run the code `print(ice_creams[3])`.
 
 > ## Long Tracebacks
 >
-> Sometimes, you might see a traceback that is very long -- sometimes they might even be 20 levels deep!
+> Sometimes, you might see a traceback that is very long 
+> -- sometimes they might even be 20 levels deep!
 > This can make it seem like something horrible happened,
 > but really it just means that your program called many functions before it ran into the error.
 > Most of the time,
@@ -107,7 +109,8 @@ sometimes just knowing *where* the error occurred is enough to fix it,
 even if you don't entirely understand the message.
 
 If you do encounter an error you don't recognize,
-try looking at the [official documentation on errors](http://docs.python.org/3/library/exceptions.html).
+try looking at the 
+[official documentation on errors](http://docs.python.org/3/library/exceptions.html).
 However,
 note that you may not always be able to find the error there,
 as it is possible to create custom errors.
@@ -239,7 +242,8 @@ That's a harder question to answer,
 because it depends on what your code is supposed to do.
 However,
 there are a few very common reasons why you might have an undefined variable.
-The first is that you meant to use a [string]({{ page.root }}/reference/#string), but forgot to put quotes around it:
+The first is that you meant to use a 
+[string]({{ page.root }}/reference/#string), but forgot to put quotes around it:
 
 ~~~
 print(hello)
@@ -283,7 +287,8 @@ Finally, the third possibility is that you made a typo when you were writing you
 Let's say we fixed the error above by adding the line `Count = 0` before the for loop.
 Frustratingly, this actually does not fix the error.
 Remember that variables are [case-sensitive]({{ page.root }}/reference/#case-sensitive),
-so the variable `count` is different from `Count`. We still get the same error, because we still have not defined `count`:
+so the variable `count` is different from `Count`. We still get the same error, 
+because we still have not defined `count`:
 
 ~~~
 Count = 0
@@ -385,7 +390,8 @@ The correct path would be `writing/myfile.txt`.
 It is also possible (like with `NameError`) that you just made a typo.
 
 A related issue can occur if you use the "read" flag instead of the "write" flag.
-Python will not give you an error if you try to open a file for writing when the file does not exist.
+Python will not give you an error if you try to open a file for writing when the file 
+does not exist.
 However,
 if you meant to open a file for reading,
 but accidentally opened it for writing,

_episodes/08-defensive.md

@@ -49,7 +49,8 @@ The first step toward getting the right answers from our programs
 is to assume that mistakes *will* happen
 and to guard against them.
 This is called [defensive programming]({{ page.root }}/reference/#defensive-programming),
-and the most common way to do it is to add [assertions]({{ page.root }}/reference/#assertion) to our code
+and the most common way to do it is to add 
+[assertions]({{ page.root }}/reference/#assertion) to our code
 so that it checks itself as it runs.
 An assertion is simply a statement that something must be true at a certain point in a program.
 When Python sees one,
@@ -92,14 +93,18 @@ are there to check that the other 80–90% are working correctly.
 Broadly speaking,
 assertions fall into three categories:
 
-*   A [precondition]({{ page.root }}/reference/#precondition) is something that must be true at the start of a function in order for it to work correctly.
+*   A [precondition]({{ page.root }}/reference/#precondition) 
+is something that must be true at the start of a function in order for it to work correctly.
 
-*   A [postcondition]({{ page.root }}/reference/#postcondition) is something that the function guarantees is true when it finishes.
+*   A [postcondition]({{ page.root }}/reference/#postcondition) 
+is something that the function guarantees is true when it finishes.
 
-*   An [invariant]({{ page.root }}/reference/#invariant) is something that is always true at a particular point inside a piece of code.
+*   An [invariant]({{ page.root }}/reference/#invariant) 
+is something that is always true at a particular point inside a piece of code.
 
 For example,
-suppose we are representing rectangles using a [tuple]({{ page.root }}/reference/#tuple) of four coordinates `(x0, y0, x1, y1)`,
+suppose we are representing rectangles using a [tuple]({{ page.root }}/reference/#tuple) 
+of four coordinates `(x0, y0, x1, y1)`,
 representing the lower left and upper right corners of the rectangle.
 In order to do some calculations,
 we need to normalize the rectangle so that the lower left corner is at the origin
@@ -111,7 +116,8 @@ but checks that its input is correctly formatted and that its result makes sense
 def normalize_rectangle(rect):
     '''Normalizes a rectangle so that it is at the origin and 1.0 units long on its longest axis.
     Input should be of the format (x0, y0, x1, y1).
-    (x0, y0) and (x1, y1) define the lower left and upper right corners of the rectangle, respectively.'''
+    (x0, y0) and (x1, y1) define the lower left and upper right corners 
+    of the rectangle, respectively.'''
     assert len(rect) == 4, 'Rectangles must contain 4 coordinates'
     x0, y0, x1, y1 = rect
     assert x0 < x1, 'Invalid X coordinates'
@@ -148,7 +154,8 @@ AssertionError                            Traceback (most recent call last)
 
 <ipython-input-20-408dc39f3915> in normalize_rectangle(rect)
       1 def normalize_rectangle(rect):
-      2     '''Normalizes a rectangle so that it is at the origin and 1.0 units long on its longest axis.'''
+      2     '''Normalizes a rectangle so that it is at the origin and 1.0 units long 
+      on its longest axis.'''
 ----> 3     assert len(rect) == 4, 'Rectangles must contain 4 coordinates'
       4     x0, y0, x1, y1 = rect
       5     assert x0 < x1, 'Invalid X coordinates'
@@ -179,7 +186,8 @@ AssertionError: Invalid X coordinates
 ~~~
 {: .error}
 
-The post-conditions on lines 17 and 18 help us catch bugs by telling us when our calculations cannot have been correct.
+The post-conditions on lines 17 and 18 help us catch bugs by telling us when our 
+calculations cannot have been correct.
 For example,
 if we normalize a rectangle that is taller than it is wide everything seems OK:
 
@@ -456,7 +464,8 @@ This violates another important rule of programming:
 
 > ## Pre- and Post-Conditions
 >
-> Suppose you are writing a function called `average` that calculates the average of the numbers in a list.
+> Suppose you are writing a function called `average` that calculates 
+> the average of the numbers in a list.
 > What pre-conditions and post-conditions would you write for it?
 > Compare your answer to your neighbor's:
 > can you think of a function that will pass your tests but not his/hers or vice versa?
@@ -466,7 +475,8 @@ This violates another important rule of programming:
 > > # a possible pre-condition:
 > > assert len(input_list) > 0, 'List length must be non-zero'
 > > # a possible post-condition:
-> > assert numpy.min(input_list) <= average <= numpy.max(input_list), 'Average should be between min and max of input values (inclusive)'
+> > assert numpy.min(input_list) <= average <= numpy.max(input_list), 
+> > 'Average should be between min and max of input values (inclusive)'
 > > ~~~
 > > {: .language-python}
 > {: .solution}

_extras/additional_material.md

@@ -3,7 +3,8 @@ layout: page
 title: "Additional material"
 permalink: /extra_material/
 ---
-A collection of facts about Python that do not fit into the main lesson either due to the scope or time constraints of the main lesson.
+A collection of facts about Python that do not fit into the main lesson 
+either due to the scope or time constraints of the main lesson.
 
 
 ## Jupyter Notebook/IPython: Who's Who in Memory

_extras/discuss.md

@@ -54,12 +54,14 @@ It does this because there are now two variables in play called `temp`:
 the parameter to `fahr_to_celsius`,
 and the parameter to `fahr_to_kelvin`.
 Having two variables with the same name in the same part of the program would be ambiguous,
-so Python (and every other modern programming language) creates a new stack frame for each function call
+so Python (and every other modern programming language) creates 
+a new stack frame for each function call
 to keep that function's variables separate from those defined by other functions.
 
 When the call to `fahr_to_kelvin` returns a value,
 Python throws away `fahr_to_kelvin`'s stack frame
-and creates a new variable in the stack frame for `fahr_to_celsius` to hold the temperature in Kelvin:
+and creates a new variable in the stack frame for `fahr_to_celsius` 
+to hold the temperature in Kelvin:
 
 ![Call Stack After Return From First Nested Function Call](../fig/python-call-stack-04.svg)
 
@@ -145,7 +147,8 @@ span of data: 20.0
 {: .output}
 
 We don't expect `diff` to have the value 20.0 after this function call,
-so the name `diff` cannot refer to the same thing inside `span` as it does in the main body of our program.
+so the name `diff` cannot refer to the same thing inside `span` 
+as it does in the main body of our program.
 And yes,
 we could probably choose a different name than `diff` in our main program in this case,
 but we don't want to have to read every line of NumPy to see what variable names its functions use

reference.md

@@ -20,7 +20,8 @@ assertion
     Programmers typically put assertions in their code to check for errors;
     if the assertion fails (i.e., if the expression evaluates as false),
     the program halts and produces an error message.
-    See also: [invariant](#invariant), [precondition](#precondition), [postcondition](#postcondition).
+    See also: [invariant](#invariant), [precondition](#precondition), 
+    [postcondition](#postcondition).
 
 assign
 :   To give a value a name by associating a variable with it.
@@ -42,7 +43,8 @@ case-sensitive
 comment
 :   A remark in a program that is intended to help human readers understand what is going on,
     but is ignored by the computer.
-    Comments in Python, R, and the Unix shell start with a `#` character and run to the end of the line;
+    Comments in Python, R, and the Unix shell start with a `#` character and 
+    run to the end of the line;
     comments in SQL start with `--`,
     and other languages have other conventions.
 
@@ -61,7 +63,8 @@ default value
 :   A value to use for a [parameter](#parameter) if nothing is specified explicitly.
 
 defensive programming
-:   The practice of writing programs that check their own operation to catch errors as early as possible.
+:   The practice of writing programs that check their own operation 
+    to catch errors as early as possible.
 
 delimiter
 :   A character or characters used to separate individual values,
@@ -175,13 +178,15 @@ postcondition
     Postconditions are often represented using [assertions](#assertion).
 
 precondition
-:   A condition that must be true in order for a function (or other block of code) to run correctly.
+:   A condition that must be true in order for a function (or other block of code) 
+    to run correctly.
 
 regression
 :   To re-introduce a bug that was once fixed.
 
 return statement
-:   A statement that causes a function to stop executing and return a value to its caller immediately.
+:   A statement that causes a function to stop executing and return a value 
+    to its caller immediately.
 
 RGB
 :   An [additive model](#additive-color-model)
@@ -248,7 +253,8 @@ tuple
 
 type
 :   The classification of something in a program (for example, the contents of a variable)
-    as a kind of number (e.g. [floating-point](#float), [integer](#integer)), [string](#string), or something else.
+    as a kind of number (e.g. [floating-point](#float), [integer](#integer)), 
+    [string](#string), or something else.
 
 type of error
 :   Indicates the nature of an error in a program. For example, in Python,