Marto Torres - PYTHON DEVELOPMENT

About the Author xiAbout the Technical Reviewers xiiiAcknowledgments xvIntroduction xvii

iii

Summary 48
Additional resources 49

Summary 99
Additional resources 100

Summary 144Additional resources 144

Error handling 157

v

Summary 180
Additional resources 181

Tidying up 239
Summary 244
Additional resources 245

Summary 280Additional resources 280

vii

Summary 343
Additional resources 343

Summary 395
Additional resources 395

viii

Summary 451
Additional resources 452

Summary 489
Additional resources 489

ix

Summary 539
Additional resources 540

Index 589x

In this chapter, we will explore the different ways that you can experiment with whatdifferent Python functions do and when is an appropriate time to use those differentoptions. Using one of those methods, we will build some simple functions to extract thefirst pieces of data that we will be aggregating and see how to build those into a simplecommand-line tool.

During any Python project, from something that youll spend a few hours developing toprojects that run for years, youll need to prototype functions. It may be the first thingyou do, or it may sneak up on you mid-project, but sooner or later, youll find yourself inthe Python shell trying code out.

There are two broad approaches for how to approach prototyping: either running apiece of code and seeing what the results are or executing statements one at a time andlooking at the intermediate results. Generally speaking, executing statements one by oneis more productive, but at times it can seem easier to revert to running a block of code ifthere are chunks youre already confident in.

The Python shell (also called the REPL for Read, Eval, Print, Loop) is most peoplesfirst introduction to using Python. Being able to launch an interpreter and typecommands live is a powerful way of jumping right into coding. It allows you to runcommands and immediately see what their result is, then adjust your input withouterasing the value of any variables. Compare that to a compiled language, where thedevelopment flow is structured around compiling a file and then running the executable.There is a significantly shorter latency for simple programs in interpreted languages likePython.

The strength of the REPL is very much in trying out simple code and getting an intuitiveunderstanding of how functions work. It is less suited for cases where there is lots of flowcontrol, as it isnt very forgiving of errors. If you make an error when typing part of a loopbody, youll have to start again, rather than just editing the incorrect line. Modifyinga variable with a single line of Python code and seeing the output is a close fit to anoptimal use of the REPL for prototyping.

For example, I often find it hard to remember how the built-in functionfilter(...)works. There are a few ways of reminding myself: I could look at the documentationfor this function on the Python website or using my code editor/IDE. Alternatively, Icould try using it in my code and then check that the values I got out are what I expect,or I could use the REPL to either find a reference to the documentation or just try thefunction out.

In practice, I generally find myself trying things out. A typical example looks like thefollowing one, where my first attempt has the arguments inverted, the second remindsme that filter returns a custom object rather than a tuple or a list, and the third remindsme that filter includes only elements that match the condition, rather than excludingones that match the condition.

>>> filter(range(10), lambda x: x == 5)
Traceback (most recent call last):

File "", line 1, in
TypeError: 'function' object is not iterable
>>> filter(lambda x: x == 5, range(10))
>>> tuple(filter(lambda x: x == 5, range(10)))
(5,)

NoteThe built-in function help(...) is invaluable when trying to understandhow functions work. As filter has a clear docstring, it may have been even morestraightforward to callhelp(filter) and read the information. However, whenchaining multiple function calls together, especially when trying to understandexisting code, being able to experiment with sample data and see how theinteractions play out is very helpful.

If we do try to use the REPL for a task involving more flow control, such as thefamous interview coding test question FizzBuzz (Listing 1-1), we can see its unforgivingnature.

Listing 1-1. fizzbuzz.py a typical implementation

for num in range(1, 101):
val = ''
if num % 3 == 0:

val += 'Fizz'
if num % 5 == 0:
val += 'Buzz'
if not val:
val = str(num)
print(val)

If we were to build this up step by step, we might start by creating a loop that outputsthe numbers unchanged:

>>> for num in range(1, 101):
...print(num)
...
1
.
.
.
98
99
100

At this point, we will see the numbers 1 to 100 on new lines, so we would start addinglogic:

>>> for num in range(1, 101):
...if num % 3 == 0:
...print('Fizz')
...else:
...print(num)
...
1
.
.
.
98
Fizz 100

Every time we do this, we are having to reenter code that we entered before,sometimes with small changes, sometimes verbatim. These lines are not editable oncetheyve been entered, so any typos mean that the whole loop needs to be retyped.

You may decide to prototype the body of the loop rather than the whole loop, tomake it easier to follow the action of the conditions. In this example, the values of nfrom 1 to 14 are correctly generated with a three-way if statement, withn=15 being thefirst to be incorrectly rendered. While this is in the middle of a loop body, it is difficult toexamine the way the conditions interact.

This is where youll find the first of the differences between the REPL and a scriptsinterpretation of indenting. The Python interpreter has a stricter interpretation of howindenting should work when in REPL mode than when executing a script, requiring youto have a blank line after any unindent that returns you to an indent level of 0.

>>> num = 15
>>> if num % 3 == 0:
...print('Fizz')
... if num % 5 == 0:

File "", line 3
if num % 5 == 0:
^
SyntaxError: invalid syntax

In addition, the REPL only allows a blank line when returning to an indent level of 0,whereas in a Python file it is treated as an implicit continuation of the last indent level.Listing 1-2 (which differs from Listing 1-1 only in the addition of blank lines) works wheninvoked aspython fizzbuzz_blank_lines.py.

Listing 1-2. fizzbuzz_blank_lines.py

for num in range(1, 101):
val = ''
if num % 3 == 0:

val += 'Fizz'
if num % 5 == 0:
val += 'Buzz'

if not val:
val = str(num)
print(val)
However, typing the contents of Listing 1-2 into a Python interpreter results in thefollowing errors, due to the differences in indent parsing rules:

>>> for num in range(1, 101):
...val = ''
...if num % 3 == 0:
...val += 'Fizz'
...if num % 5 == 0:
...val += 'Buzz'
...
>>>if not val:

File "", line 1
if not val:
^

IndentationError: unexpected indent
>>>val = str(num)
File "", line 1

val = str(num)
^
IndentationError: unexpected indent
>>>
>>>print(val)

File "", line 1
print(val)
^

IndentationError: unexpected indent

Its easy to make a mistake when using the REPL to prototype a loop or conditionwhen youre used to writing Python in files. The frustration of making a mistake andhaving to reenter the code is enough to undo the time savings of using this method overa simple script. While it is possible to scroll back to previous lines you entered usingthe arrow keys, multiline constructs such as loops are not grouped together, making itvery difficult to re-run a loop body. The use of the>>> and... prompts throughout thesession also makes it difficult to copy and paste previous lines, either to re-run them orto integrate them into a file.