Fix lint.

Author: ZeroIntensity

peps/pep-0788.rst

@@ -173,14 +173,14 @@ cause many of the issues outlined in this proposal, so removing daemon threads
 could be seen as a potential solution. The main argument for removing daemon
 threads is that they're a large cause of problems in the interpreter:
 
-    Except that daemon threads don’t actually work reliably. They’re attempting 
+    Except that daemon threads don’t actually work reliably. They’re attempting
     to run and use Python interpreter resources after the runtime has been shut
     down upon runtime finalization. As in they have pointers to global state for
     the interpreter.
 
 In practice, daemon threads are useful for simplifying many threading applications
 in Python, and since the program is about to close in most cases, it's not worth
-the added complexity to try and gracefully shut down a thread. 
+the added complexity to try and gracefully shut down a thread.
 
     When I’ve needed daemon threads, it’s usually been the case of “Long-running,
     uninterruptible, third-party task” in terms of the examples in the linked issue.
@@ -206,15 +206,15 @@ Joining the Thread isn't Always a Good Idea
 *******************************************
 
 Even in daemon threads, it's generally *possible* to prevent hanging of
-native threads through :mod:`atexit` functions. 
+native threads through :mod:`atexit` functions.
 A thread could be started by some C function, and then as long as
 that thread is joined by :mod:`atexit`, then the thread won't hang.
 
 :mod:`atexit` isn't always an option for a function, because to call it, it
 needs to already have an :term:`attached thread state` for the thread. If
 there's no guarantee of that, then :func:`atexit.register` cannot be safely
 called without the risk of hanging the thread. This shifts the contract
-of joining the thread to the caller rather than the callee, which again, 
+of joining the thread to the caller rather than the callee, which again,
 isn't done in practice.
 
 For example, large C++ applications might want to expose an interface that can
@@ -359,7 +359,7 @@ Preventing Interpreter Shutdown with Reference Counting
 -------------------------------------------------------
 
 This PEP takes an approach where an interpreter is given a reference count
-that prevents it from shutting down. So, holding a "strong reference" to the 
+that prevents it from shutting down. So, holding a "strong reference" to the
 interpreter will make it safe to call the C API without worrying about the
 thread being hung.