Errata

For the score algorithm:

def scoreMove(self, T1, T2):
(row, col) = T1
((countRows, countCols), (countDiag1, countDiag2)) = T2
return (
countCols.get((col, self.machineMark), 0) * 11 +
countRows.get((row, self.machineMark), 0) * 11 +
countDiag1[self.machineMark] * 11 +
countDiag1[self.machineMark] * 11
+
countCols.get((col, self.userMark), 0) * 10 +
countRows.get((row, self.userMark), 0) * 10 +
countDiag1[self.userMark] * 10 +
countDiag1[self.userMark] * 10
+
countCols.get((col, Empty), 0) * 11 +
countRows.get((row, Empty), 0) * 11 +
countDiag1[Empty] * 11 +
countDiag1[Empty] * 11)

It seems you counted the same diagonal (countDiag1) twice.

Shouldn't you use countDiag2 as well?

countDiag1[self.machineMark] * 11 +
countDiag2[self.machineMark] * 11

countDiag1[self.userMark] * 10 +
countDiag2[self.userMark] * 10

countDiag1[Empty] * 11 +
countDiag2[Empty] * 11)


Am I missing or assuming something wrong here???

Note from the Author or Editor:
[NO EDITS REQUIRED]

Yes, column 2 should probably be counted per your post. But this code is in an external supplemental example, is not shown in the book, and is not used by the book's briefly-presented PyToe example, which selects moves with the much better Minimax search alternative in the referenced file. Hence, no update required, but the following provides some historical context for interested readers.

This code is part of the PyToe tic-tac-toe game program. It appears in just 1 of the 5 move selection alternatives in the external example file (not counting variants never ported to 3.X form). It uses a very simplistic scoring heuristic, which was later subsumed by alternatives that proved better (and not just because of this typo).

Frankly, I haven't seen this code since it was written for the 2nd Ed in 1999; it wasn't used after initial development, and has largely existed as cruft since then. Even the 2nd Ed did not list any PyToe source code, because it requires some AI background that was deemed beyond the book's scope,

Since then, the 3rd and 4th Eds have continued to relegate PyToe to an external-only example, mentioned only as supplemental reading, and presented with just a screen shot and blurb to pique interest. Like the Holmes expert system similarly mentioned in the book, AI gaming is fun stuff, but out of scope in general.

In other words, great catch: I'm amazed that this obscure code received scrutiny after 16 years.

For the following lines of code in treeview_subclass.py:

parent.__colpos + Colsz*.25, # from x-y, to x-y
parent.__rowpos + Rowsz*.5,
colpos + Colsz*.25, rowpos, arrow='last', width=1)
node.__rowpos = rowpos
node.__colpos = colpos # mark node, private attrs

You noted that __rowpos and node__pos are private attrs (name mangled).

But is that really the case? Aren't you just assigning an attribute to an object that just so happens to have a double underscore and assigning a value to it rather than defining it in the class definition. For example:

Class A:
__x = 1

>>>A.__x
AttributeError: type object 'A' has no attribute '__x'

vs.

Class A:
pass

A.__x = 1

>>>A.__x
1

Doesn't the fact that accessing the attributes in the following code:

parent.__colpos + Colsz*.25, # from x-y, to x-y
parent.__rowpos + Rowsz*.5,

imply that they they aren't private?

I could have just easily removed the underscores and the code would work just the same:

parent.colpos + Colsz*.25, # from x-y, to x-y
parent.rowpos + Rowsz*.5,
colpos + Colsz*.25, rowpos, arrow='last', width=1)
node.rowpos = rowpos
node.colpos = colpos

Note from the Author or Editor:
[NO EDITS REQUIRED]

No; sorry, but this post seems to reflect a lack of understanding of Python's pseudo-private attributes mechanism, an oddly obscure but very useful tool. Please see Learning Python for language fundamentals like this; as stated in the Preface, they are prerequisite to the applications-programming topics in Programming Python. One can't really jump into applications successfully without understanding language basics. In any event, this post refers to code included as a supplemental example but not listed or covered in the book itself, and the code referenced is not in error.

As a brief review, though, pseudo-private names are coded with double underscore prefixes, and are expanded by Python at each of their appearances anywhere in the class. In this case, the double underscore names are used intentionally for administrative data added by the tree sketcher, so that they won't clash with attribute names used by the application whose trees are being sketched. Because each of the class's "__X" names is stamped with the class name automatically, they are different from the same name used in other classes. In simpler terms:

>>> class TreeViewer:
... def __init__(self):
... self.rowpos = 88 # non-mangled: application's data
... self.__rowpos = 99 # mangled, pseudo-private: tool's data
... def update(self):
... self.__rowpos += 1 # update mangled tool name (only!)
...
>>> tv = TreeViewer()
>>> tv.__dict__
{'rowpos': 88, '_TreeViewer__rowpos': 99}

>>> tv.update()
>>> tv.__dict__
{'rowpos': 88, '_TreeViewer__rowpos': 100}

>>> tv.rowpos
88
>>> tv._TreeViewer__rowpos
100

By mangling the names to include the enclosing class's name, Python more or less guarantees that they are unique, distinct from the attributes of any other class in an application, and not accessible from outside the class without using their fully-mangled form (in this case, obj._TreeViewer__rowpos) .

It's not full privacy (see the decorators chapter in Learning Python 5E for an approach to implementing that with attribute tools), but suffices to minimize name collisions. If the code had just used "node.rowpos" without the underscores, it would possibly overwrite an attribute of the same name being used by the subject application.

C:\...\ PP4E\ System\ Streams > type adder2. py
import sys
sum = 0
while True:
line = sys.stdin.readline()
if not line: break
sum + = int( line)
print( sum)

IF THE LINE IS EMPTY, IT SEEMS TO READ '\n' so that 'not line' is still true. What am I missing?

Also, another form is:

import sys
sum = 0
line = '0'
while line != '\n':
sum += int(line):
line = sys.stdin.readline()
print( sum)

I have trouble with the 'while True' construct, so I try to avoid it.

Note from the Author or Editor:
[No changes required; information reply only]

This example assumes there are no empty lines in the file -- only lines having numbers -- and hence doesn't allow for a bare '\n' (though you're welcome to expand the 'if' statement to do so). This code also relies on the fact that file.readline(), unlike input(), returns the empty string at end-of-file, not a '\n' or an exception (this may or may not be part of the confusion):

~$ py3
>>> fname = '/Users/blue/Documents/temp.txt'
>>> open(fname, 'w').write('line1\nline2\n')
>>> print(open(fname).read())
line1
line2

>>> fobj = open(fname)
>>> fobj.readline()
'line1\n'
>>> fobj.readline()
'line2\n'
>>> fobj.readline()
''

WRT the alternate coding: you're version works well too, of course, and may be preferred by some structured-programming purists, but the 'while True:' idiom is pervasive in Python code. Personally, I'd probably code a simple loop like this using either the iterator- or generator-based versions shown in the book next, and reserve explicit loops for cases where there was more to the processing logic than a summation:

for line in sys.stdin: sum += int(line) # file line iterator
sum(int(line) for line in sys.stdin) # generator form

The two given links to the author's website are equal:
1. "As before, examples, updates, corrections, and supplements for this book will be maintained at the author’s website, which lives officially at the following URL:

learning-python.com/books/about-pp4e.html"

2. "This page at my book support website will contain links to all supplemental information related to this version of the book. Because I don’t own that domain name, though, if that link ceases to be during this book’s shelf life, try the following alternative site as a fallback option:

learning-python.com/books/about-pp4e.html (alternative location)"

I excluded 'http' as URLs aren't allowed to be present in the description of the error.

Note from the Author or Editor:
I'm not sure what the poster is describing here; is the same link text repeated twice in Safari? That's not what I'm seeing in the current book PDF or print, which lists two different URLs in the Preface - an original default and a newer alternative:

http://www.rmi.net/~lutz/about-pp4e.html
http://learning-python.com/books/about-pp4e.html (alternative location)

As of today, the first of these forwards to the second, and the second is automatically redirected to the current page at the following URL (via Apache rewrite-rules magic):

https://learning-python.com/about-pp4e.html

Hence, the Preface's links both resolve to the same URL today, but the Preface's referenced text reflects an expected future which has now happened, and I don't see any reason to rewrite this history today. That said, it's marginally better to be current on the second link, so let's change the first of the following to the second in the Preface:

http://learning-python.com/books/about-pp4e.html (alternative location)
https://learning-python.com/about-pp4e.html (alternative location)

BUT: if Safari indeed lists the same text for both links here, please let me know. It's possible that this has been changed automatically in Safari, but that would invalidate the Preface's narrative, and be an incorrect glitch from my perspective -- and be cause for concern over how many other links Safari may have munged wrongly...

I had to put

#!/usr/bin/env python

at the top of the code
Example 1-34. PP4E\Preview\cgi-bin\peoplecgi.py

Otherwise, the browser will try to download the script rather than executing it.


Not sure why, but my environment is Python 3.4.1 on mac os 10.10.5, using firefox browser,
and using the webserver.py script from the book, but I customized
the
Example 1-32. PP4E\Preview\webserver.py

a little bit:

instead of:
srvraddr = ("" port)

I used
srvraddr = ("python1", port)

Because that's how I've setup my host on my machine.

Note from the Author or Editor:
EDIT:
Looks like we have space for a clarification, so: change the start of page 55's last paragraph from the first of the following to the second:
"We’ll revisit the tools used in this example later in this book."
"We’ll revisit the tools used in this example later in this book (and explore Unix CGI script configuration requirements we’ll skip here)."

[Discussion only follows]

Not sure why your setup required the hostname change you described, but this example and others like it work for me on a Mac today if I perform the following additional configuration steps that are not required on the book's Windows test platform, but are all covered later in the book:

1) Change the server script's port number to 8888 from the precoded 80, and use "localhost:8888" in all URLs, as described in this chapter. (A "su" might enable running a server on port 80, but I didn't care to try.)

2) Add the initial "#!/usr/bin/env python3" (or "#!/usr/bin/python for 2.X) as you suggested.

3) Convert the CGI script file to UNIX end-line format (from DOS format), using a simple utility script I have (there are many other ways to do this: see the web).

4) Give the CGI script executable permission with a "chmod a+x cgi101.py".

These steps are all spelled out in detail in Chapter 15, where CGI scripting is covered in full. As stated up-front, the chapter hosting the example in question is just a quick preview that's deliberately short on such details for space.

As a broad rule, this book's web scripting code does work as shown and described (running locally, on Windows, in Python 3.1, etc.). Beyond that, though, both Python's evolution and CGI and server details are too variable to guarantee universal portability. That said, the examples do work on the latest Pythons and platforms, and I'm glad that some readers are able to work out the kinks on their computers as needed.

In order to make "Example 1-34. PP4E\Preview\cgi-bin\peoplecgi.py" work correctly, I had to change the following:

in
def htmlize(adict):
new[field] = cgi.escape(strvalue))


instead of:

new[field] = cgi.escape(repr(value))


And in

def updateRecord(db, form):
setattr(record, field, form[field].value)

instead of:
setattr(record, field, eval(form[field].value))


Otherwise, the webserver.py would crash and I would have a blank screen in the browser

Note from the Author or Editor:
EDIT:
Looks we have space for a clarification, so: on page 65, expand the start of the last paragraph from the first of the following to the second, with literal font on its "eval":
"To update a record, fetch it by key, enter new values in the field inputs,"
"To update a record, fetch it by key, enter new values in the field inputs (and remember to quote string input values here just as in the earlier versions for the script's eval),"

[Discussion only follows]

No - you don't need to make the changes you suggested. You only need to remember to quote string values in the form's fields as in code (enter 'spam' instead of spam), and the example works as shown and described in the latest Pythons, and with no code changes.

You probably missed the discussion of eval() in the console and GUI versions of this example which precede it. Though it's not repeated here a third time, the earlier variations make it fairly clear that the form field's values (except for the key) are assumed to be in Python code syntax, and are run through eval() to convert them to Python objects. This is deliberate so that digits are converted to numbers, but means you must quote string values. Here's one of the excerpts from the chapter (see also the code's admittedly-terse comment "# eval: strings must be quoted"):

"""
Notice how we’re using repr again to display field values fetched from the shelve and eval to convert field values to Python objects before they are stored in the shelve. As mentioned previously, this is potentially dangerous if someone sneaks some malicious code into our shelve, but we’ll finesse such concerns for now.

Keep in mind, though, that this scheme means that strings must be quoted in input fields other than the key—they are assumed to be Python code. In fact, you could type an arbitrary Python expression in an input field to specify a value for an update. Typing "Tom"*3 in the name field, for instance, would set the name to TomTomTom after an update (for better or worse!); fetch to see the result.
"""

With your suggested edits, every field value will be a text string object. That works (and you won't have to quote string values in the form), but is limiting, and was not the intent of this chapter's running example. Really, fields should probably have associated type information, but that's too much infrastructure for this simple preview-chapter example.

All that being said I'm adding a parenthetical clarification here for readers who may similarly have skipped to the web version. For the record, I've just verified that this example works under Python 3.5 on both Windows and Mac OS X when strings are quoted as required, though you must also make the unrelated configuration changes on Mac OS X and Linux outlined in the reply to your other post here.

"C:\...\PP4E\Tools> python find.py *.py .. | more"
It seems I have to quote "*.py" for this command to work in Linux. Didn't try Windows though.

Note from the Author or Editor:
Changing this to a clarification, not an errata. To address, change the very end of paragraph 2 on Page 322 from:
"...standard input stream:"
to:
"...standard input stream (remember to quote the "*.py" on Unix and Linux shells only, to avoid premature pattern expansion):"

[DISCUSSION ONLY FOLLOWS]
The report is correct about needing to quote some command-line arguments on Linux (only), and this does merit a note here. This finder directory tree search script matches the passed-in "*.py" pattern itself, so we don't want a Linux shell to do expansion before it's passed in.

However, shell differences are mentioned elsewhere; this book runs all its examples on Windows, where this isn't an issue; and the book cannot note shell differences at each command where syntax diverges without becoming a shell programming guide too.

On this specific point, the following text appears on Page 106 (before the command line in question) in an early section devoted to command lines in general:
"""
(portability note: you may need to add quotes around the *.py in this and other command-line examples to prevent it from being expanded in some Unix shells):
"""
Moreover, Unix shell globbing behavior is also described on the earlier Page 166, and the closer Page 320-321.

Both linear readers of the book and Linux users in general should probably be aware of the issue well enough to argue against redundant warnings throughout an already large text (and quoting arguments in general for Linux readers would likely confuse others with less command-line experience to draw from).

Nevertheless it's worth adding the text in the book and retaining this note as a reminder for Linux readers here -- thanks for the report.

Original Command

"C:\...\Examples\PP4E> Tools\cleanpyc.py"

Should be:

"C:\...\Examples\PP4E> Tools\cleanpyc.py .."

Since the output shows the the .pyc files being removed in the parent directory tree.

Note from the Author or Editor:
[NO EDITS REQUIRED, informational only, changed to clarification]

Not true. A ".." wouldn't hurt, but is not required here. When running the script from one level up in the shell, the current working directory (CWD) used by default is the directory the shell is working in, not the script's own directory. Using Python 3.3, in a Windows shell (Command Prompt):

C:\...\PP4E> Tools\cleanpyc.py
=> C:\...\PP4E\Ai\TicTacToe\__pycache__\tictactoe_lists.cpython-33.pyc
=> C:\...\PP4E\Dbase\__pycache__\testdata.cpython-33.pyc
=> C:\...\PP4E\Dbase\__pycache__\__init__.cpython-33.pyc
=> C:\...\PP4E\Dstruct\Classics\__pycache__\btree.cpython-33.pyc

This is why the immediately-following example in the book is run one level down, in the scripts own directory, to illustrate the difference:

C:\...\PP4E\Tools> cleanpyc.py .
=> .\find.pyc
=> .\visitor.pyc
=> .\__init__.pyc
Found 3 files, removed 3

For a refresher on this, see "CWD, Files, and Import Paths" on page 104.

Original line of code:

def trace(*args): print(*args) # with spaces between

Should be:

def trace(*args): print(args) # with spaces between

The asterisk should be removed in the print statement.

Note from the Author or Editor:
[NO EDITS REQUIRED, retained as informational, changed to clarification]

No, the star is required. This is a common pattern for general trace routines; the first star in the header means "collect any number of positional arguments in a tuple", and the star in the print() call means "unpack the arguments tuple into separate arguments". The combined effect allows any number of arguments, and passes them on to print() so that they display individually, with spaces between them, and without enclosing tuple parenthesis:

>>> def trace(*args): print(*args) # with spaces between
...
>>> trace('spam', 99, 3.1415)
spam 99 3.1415
>>> trace('spam')
spam

See Learning Python for more background on such language fundamentals.

[Last changed August 2015, No Edits Required, informational only]

ASSORTED TKINTER GUI NOTES:

1) Dialogs and wait_visibility() on Linux (page 442)

On Linux, you probably need to call win.wait_visibility() before win.grab_set() when creating a modal dialog this way. This platform disallows grabs until a window is visible; without the added call, the grab fails with an exception and the dialog isn't modal.

This book's examples were run and tested on Windows where the extra call isn't required, and there's unfortunately no room to insert a note on this page. I'm posting it here as a clarification instead.

For more on this call, see its usage in the calendar program example I posted as a supplement for book readers at:

/learning-python.com/frigcal/Readme-frigcal.html

The call is demonstrated in this program's file frigcal.py, using this code:

if sys.platform.startswith('linux'):
window.wait_visibility()
window.grab_set()

2) Uniform gridding: tables (page 564)

The frigcal program and file also illustrates uniform-sized grids, similarly not shown in the book. It uses the following code (experiment on your own to see its effect):

for week in range(MAXWEEKS):
alldaysfrm.rowconfigure(week, weight=1, uniform='a')
for day in range(7):
alldaysfrm.columnconfigure(day, weight=1, uniform='a')

3) Unicode limitations

The Tk library underlying Python's tkinter has also been shown to have limits with respect to allowable Unicode characters. Odd emoticons in emails, for example, can wreak havoc with email clients like the book's PyMailGUI; code workarounds as warranted (e.g., sanitize text before storing in GUI text fields).

4) Widget.after() hangs

Finally, it's been recently discovered that the tkinter widget.after() timer event can be broken by changes to the system time. In short, the underlying Tk library computes an absolute time for running a scheduled after() event. If Windows automatically adjusts your clock, pending after() callbacks may appear to hang, because their absolute firing time is not reached. This can manifest in the book's PyClock clock and PyMailGUI email client examples, as both rely on timer events (to redraw clocks, and run queued thread actions). This is a Tk issue, and may be repaired in future Tk releases; for now, try changing your clock to unhang such programs.

The method of setting a window icon as used in the generic _window class, does not work on linux. This seems to be part because the .ico file is only for windows and part because tk has a hard time decoding any image file. Following code seems to work:

root = Tk()
img = PhotoImage(file='your-icon')
root.tk.call('wm', 'iconphoto', root._w, img)

Note from the Author or Editor:
[No Edits Required: informational only, changing this report's type from minor technical mistake to clarification.]

It's true that Windows ".ico" files won't generally work on Linux, but:

1) This is pretty clearly explained in a big paragraph on page 424, where tk's iconbitmap call is first covered in depth, and mentioned parenthetically on page 44 at a preview example (plus, the book makes its use of Windows for running examples explicit throughout).

2) The _window class on Page 631 referred to in this post should not cause its clients to fail on Linux, as it wraps the icon call in a exception handler and simply ignores the error on other platforms (to be verified, but it should only skip the custom window icon step and continue).

So, this isn't an errata per se; the example works as shown, and requires tweaking outside Windows for custom icons as described in the book. That's one of the unavoidable platform dependencies of GUIs, and it wasn't possible to cover every variant.

That said, I'm retaining this note here as a constructive and useful pointer for other Linux readers who may want to use a custom window icon too; thanks for the suggestion.

On Linux, you'll probably also want to customize the _window class's iconpatt string, used to search for an icon file automatically if none is passed in (see the code: it's "'*.ico" as is).

Not sure if I'm doing something wrong but there does not seem to be a PhotoImage module/class which the PyGadgets or PyDemo script tries to use. It tries to import it from Gui/PIL, but it does not exist anywhere in the PP4E tree. If I use the PhotoImage that exists in tkinter, a run-time error results when it references an open( no such method.
I am using Python 3.7.6 (v3.7.6:43364a7ae0, Dec 18 2019, 14:18:50)

Note from the Author or Editor:
[No changes required] Have you worked this out on your own yet? PhotoImage is a class in Python's standard tkinter module, and appears with documentation at numerous places in the GUI parts of the book (especially the introduction and tutorials).

As also covered in the text, the third-party PIL library (now called Pillow but still imported as PIL) has a PhotoImage class too, which replaces tkinter's, and adds more advanced image-type support and extra functionality leveraged by the book's examples. To use this, you must install Pillow separately from Python. See page 491 and later for PIL, especially; example:

% python3
>>> from tkinter import PhotoImage # the standard lib's module
>>> PhotoImage
<class 'tkinter.PhotoImage'>
>>>
>>> from PIL import ImageTk # the PIL/Pillow replacement
>>> ImageTk.PhotoImage
<class 'PIL.ImageTk.PhotoImage'>

One note: if you're on Linux, the incantation for installing PIllow is a bit obscure (and the install docs at https://pillow.readthedocs.io/en/stable/installation.html seem out of date); the following suffices on Ubuntu today, and a web search for "ImageTk PiIlow linux" turns up additional hints:

sudo apt-get install python3-pil python3-pil.imagetk

One nit: the PIL project eventually became a fork called Pillow; the two are almost identical, but to use Pillow instead of PIL, you must change any appearances of the first of the following to the second:

import Image
from PIL import Image

I don't, however, see the first form used anywhere in the book's examples, so this isn't relevant to your post. I'd suggest ensuring that you've installed and are using Pillow's class, if your calls are not working. And if you're truly curious, you can find PhotoImage's source code in the package folder "tkinter/" of Python's standard libs install on your computer.

This post was retained in case other readers have similar queries, but its type was changed from "serious mistake" to "clarification." For more details, try these related book-support pages:

https://learning-python.com/README-PP4E-PY33-PY35.html#s4
https://learning-python.com/pp4e-updates.html#pil

In references to directory and file:

Tools\Scripts\ftpmirror.py

They do not exist.

Note from the Author or Editor:
[NO EDIT REQUIRED, retained as informational only]

No, Tools\Scripts\ftpmirror.py does exist, at least as of Python 3.3, in the standard Windows install.

This post refers to a cryptic program comment and brief narrative mention that refer to Python's ftpmirror script as another example to study, as it's related to the FTP directory tree deletion script in the book.

This script has been standard on Windows installs for many years, but has moved in the past, and may be elsewhere on Macs or Linux. Run a find to locate if needed, and try a web search or Python's source-code package as a last resort. This isn't discussed further in the book than this brief comment mention, so no elaboration is required.

I am also getting a raise of 10% for Doe. Looks like Manager glass's customization giveRaise doesn't work.

I tried it with my code and using downloaded examples from the book.

I am using latest Python 3.6.3 on conda 4.4.6

Note from the Author or Editor:
[Not errata, no changes required, retained as clarification only]

No, this code in the book and its examples package works as shown and described: the Manager instances gets an extra 10% bonus tacked on to the raise amount passed in. This is true for both the original person.py and manager.py pair, as well as the person_alternative.py recoding. Perhaps you've already realized this on your own after the post, but the results in all cases are fairly clear about the total raises applied for Managers:

>>> x = 50000
>>> x *= (1 + .10) # if just 10% was applied (non-Manager Persons)
>>> '%.2f' % x
'55000.00'
>>>
>>> x = 50000
>>> x *= (1 + .10 + .10) # a 10% raise plus a 10% bonus (Managers)
>>> '%.2f' % x
'60000.00'
>>>
>>> x = 50000
>>> x *= (1 + .20 + .10) # a 20% raise plus a 10% bonus (other examples)
>>> '%.2f' % x
'65000.00'

If you're still not convinced, I encourage you to trace through the examples again and desk-check their results; the small details can be confusing on first glance.

This is not an error but a suggestion for easing the problem of delayhed evaluation of a function when its arguments may have changed. At location 9916 on Kindle version.

But you must still sometimes use defaults instead of enclosing scopes

Lutz, Mark. Programming Python (Kindle Location 9916). O'Reilly Media. Kindle Edition.

You could Curry the function, then give the local arguments. It is a little different from the usual Curry because you don't want to evaluate the function after all arguments have been passed, but on the next call. That way the arguments are evaluated when added.

Tyhe example at location 9900 looks like:

command = Curry handler)(X, 'spam')

Note from the Author or Editor:
[No changes required - informational only] (This topic starts on Page 387 of the printed book, and is also covered in Learning Python's Chapter 17.)

Thanks for your note. Naturally, there's no room to expand on this topic in the book today, but I'm retaining this as a pointer here for other readers. The web has additional resources on currying that may be of interest.

In short, currying (and its cousin, partial application) are indeed ways to retain state for use in later calls, like the state needed in the referenced example -- the current values from an enclosing scope. Still, Python has additional schemes which some may consider more traditionally Pythonic. As discussed in the book, these include nested function closures, as well as instances of classes. The latter can make the state retention explicit (and arguably less "magic") with attribute values filled out in __init__, and either called or bound methods, or __call__ to implement a function-call interface. Because Python has such tools, currying is often a secondary option in its realm, where "flat is better than nested" is still considered a coding virtue.

While all such options are interesting from a programming languages perspective, they may also be a bit much in the referenced example. In its case, default argument values suffice to attach values to the lambda functions themselves, and serve well and simply as "memory" for later calls. Then again, there's more than one way to bind data to function calls, especially if you're coming from a background in other languages.