Notable for code archaeology: the docstrings weren't in the previous version[].

(He also switched from manually implementing counting behavior with a Dict to a Counter, added the P function which replaces an inline dict lookup, similarly added the candidates function, changed the somewhat awkward known_edits2 function to just edits2, and reorded some things.)

[] http://web.archive.org/web/20160408180602/http://norvig.com/...

edit: small edits

Came here to say this. I've combed through his pieces many times over just to glean the way he structures his code. Here, he got my head spinning for a minute with

  return set(w for w in words if w in WORDS)

and made a mental note to use that idiom in the future.

As for doc strings, well, this is just a toy piece of code after all. The main purpose for the code is to be read, instead of actually used. something something hobgoblin of little minds

Edit: formatting.

You can also use the set-comprehension syntax, which functions equivalently but looks slightly nicer:

    return {w for w in words if w in WORDS}

could have also directly used the intersection operator on the sets:

    return words & WORDS

or slightly more verbose, but maybe more clear for colleagues who don't regularly use sets in Python:

    return words.intersection(WORDS)

> return words & WORDS

Not quite. It'd have to be set(WORDS) instead of WORDS -- which'd be expensive. Or WORDS.keys(), which I'm not sure about -- I'd have to benchmark it.

You would only need to do set(WORDS) once at the beginning of the program, so its amortized cost is low.

I wouldn't worry about the expense of set construction vs the expense of an n-squared algorithm.

caught me, I hadn't read through the article, wasn't sure whether or not WORDS was a set or a dict. Like desdiv points out, this isn't a big deal, you can maintain an equivalent WORDS structure that is a set.

That was one of the phrases used in the program that taught me to touch type. Stuck with me for decades..and has been almost as useful to me as learning to touch type...

that is a great idiom. i remember the first time i saw it (possibly in is very essay), i thought it was awesome. I use it all over the place now. it is similiar to the javascript ternary operator [1], which I also find to be very useful

   var varX = (boolean) ? 'X' : 'Y'

[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Pretty much every language has a ternary conditional operator: C++, Java, Python, C#, Ruby....

This isn't the Python ternary which is:

  varX = 'X' if boolean else 'Y'

  # And is chainable in a more natural way than C*:
  varX = 'X' if boolean else 'Y' if other else 'Z'

What is wrong with his docstrings?

Nothing's wrong with them. Though it is more usual to use triple quotes for docstrings even if they fit on one line (see PEP 257, "Triple quotes are used even though the string fits on one line. This makes it easy to later expand it.").

Easy in the sense of more pleasant version control diffs.

Couldn't it cause issues with "object definition" code in REPLs and editors, and interfere with documentation generators, i.e. [Sphinx](http://www.sphinx-doc.org/en/stable/)?

I'd be surprised if so. Most of those tools rely on the built-in parser, which treats all string literals similarly.