paragraph style improved

Author: thomasWeise

text/main/basics/collections/ruff/ruff.tex

@@ -9,13 +9,15 @@
 \listingToolOutput{lists:lists_error:mypy}{%
 The results of static type checking with \mypy\ of the program given in \cref{lst:lists:lists_error}.}%
 %
+\begin{sloppypar}%
 Recently, we learned that static code analysis tools can help us to discover subtle problems in our programs.
 Obviously, when dealing with more complex datastructures like lists, there are also more potential problems, more mistakes that one could make.
 Let us look at the very short example program \programUrl{lists:lists_error} in \cref{lst:lists:lists_error}.
 The program consists of only two lines, \pythonil{my_list: list[str] = list([1, 2, 3])} and \pythonil{print(my_list)}.
 It does not have any \emph{error} in the strict sense.
-We can execute it just fine and it will produce the output \textil{[1, 2, 3]} as shown in \cref{exec:lists:lists_error}.
-
+We can execute it just fine and it will produce the output \textil{[1, 2, 3]} as shown in \cref{exec:lists:lists_error}.%
+\end{sloppypar}%
+%
 However, upon closer inspection, we discover some issues.
 In a first step, we would apply \mypy~(as~\cref{ut:mypy}) to check for problems with the types of variables.
 And indeed, \cref{exec:lists:lists_error:mypy} shows us \emph{three} errors!
@@ -83,14 +85,16 @@
 The corrected version of~\cref{lst:lists:lists_error}, taking into account the information given by \mypy\ in \cref{exec:lists:lists_error:mypy} and \ruff\ in \cref{exec:lists:lists_error:ruff}.}{}%
 %
 %
+\begin{sloppypar}%
 In \cref{lst:lists:lists_fixed} we implement the three recommendations from the two tools as program \programUrl{lists:lists_fixed}.
 We change the \pgls{typeHint} of the list to \pythonil{list[int]}, which solves the type confusion that \mypy\ discovered.
 We remove the useless copying of the list as \ruff\ recommended.
 Finally, we add a proper \pgls{docstring} at the top of the file, in which we even document the changes we applied.
 The output \cref{exec:lists:lists_fixed} of the new program remains the same.
 But now, both tools are satisfied, as shown in \cref{exec:lists:lists_fixed:mypy,exec:lists:lists_fixed:ruff}.
-And our program is much clearer and faster.
-
+And our program is much clearer and faster.%
+\end{sloppypar}%
+%
 \gitExec{exec:lists:lists_fixed:mypy}{\programmingWithPythonCodeRepo}{.}{_scripts_/mypy.sh collections lists_fixed.py}%
 \listingToolOutput{lists:lists_fixed:mypy}{%
 The results of static type checking with \mypy\ of the program given in \cref{lst:lists:lists_fixed}.}%

text/main/controlFlow/exceptions/exceptions.tex

@@ -802,14 +802,16 @@
 We must make sure to definitely close this so-called text stream again, regardless what happens from now on.
 We know that this can be done with a \pythonilIdx{try}-\pythonilIdx{finally} statement.
 We simply put \pythonil{stream_out.close()}\pythonIdx{close}\pythonIdx{IO!close} into the \pythonilIdx{finally}~block.
-It will thus definitely be called and we thus ensure that \pythonil{stream_out} will be closed.
-
+It will thus definitely be called and we thus ensure that \pythonil{stream_out} will be closed.%
+%
+\begin{sloppypar}%
 Into the \pythonilIdx{try}~block, we put \pythonil{stream_out.write("Hello world!")}.
 This line will write the string~\pythonil{"Hello world!"} to the file.
 This could, of course, fail.
 Maybe our hard disk does not have enough space left to store this string.
-But even if it fails, the \pythonilIdx{finally} block will make sure to close the file.
-
+But even if it fails, the \pythonilIdx{finally} block will make sure to close the file.%
+\end{sloppypar}%
+%
 So after the block, the file is closed.
 We could now open it in a text editor and would find in there the text that we had written.
 Instead, we want to use code to read the text again right away.

text/main/controlFlow/functions/functions.tex

@@ -985,6 +985,7 @@
 %
 \pythonSyntax{syntax/callable.py}%
 %
+\begin{sloppypar}%
 Inside the \pythonil{Callable[...]}, we first provide the list of types of the parameters of function, again in square brackets.
 Then follows a comma~\pythonil{,} and then follows the return type.
 The \pythonil{f: Callable[[float], float | int]} in our listing thus states that our function \pythonil{integrate} expects, as first parameter, \emph{another function}~\pythonil{f}.
@@ -993,8 +994,9 @@
 Notice that the type \pythonilIdx{Callable} is provided by the module~\pythonilIdx{typing}\footnote{%
 \cite{PSF:P3D:TPSL:ACO}~states that this import is now deprecated and we should use \pythonil{collections.abc.Callable}\pythonIdx{collections.abc} instead. %
 In the past, this created some errors for me, so for now we stick with using~\pythonilIdx{typing}.}, %
-so we need to import it first if we want to use it.
-
+so we need to import it first if we want to use it.%
+\end{sloppypar}%
+%
 The actual implementation of \pythonil{integrate} is straightforward.
 Inside the function, we add up the different trapezes as shown in the simplified equation in \cref{fig:normalDistPdfInteg}.
 Only the values of \pythonil{f} at the interval ends \pythonil{a} and \pythonil{b} need to be halved in the sum.