That's actually nice and straight forward and relatively simple. I had expected something over engineered with at least parts of the code dedicated on demonstrating how much smarter the code writer is than you. But it's not. Just a simple parser.
I expected the same (complex project structure, too many files, difficult to read, etc), but I love everything about this library. Easy to read, concise code, in two simple files. Very well tested, both by automated tests and the real world. Sticks to the Unix philosophy: does one thing and does it well.
Can you imagine how many billions of time this code has been executed? I love software like this.
You're very much taking that out of context. Read the entire section. There's a grand total of 7 sentences in there. It literally says:
If you're going to have to explain it at the next code review, you should comment it now. Complicated operations get a few lines of comments before the operations commence. Non-obvious ones get comments at the end of the line.
The section you're quoting says:
On the other hand, never describe the code. Assume the person reading the code knows Python (though not what you're trying to do) better than you do.
I think you might be misreading the meaning of this? If the person reviewing knows the language better than you, they they are hopefully less likely to tolerate "clever code", not more.
By "clever code" we're talking about weird unidiomatic tricks and hacks that maybe writes things in a slightly shorter or in a fractionally more (unnecessarily) optimised way, and makes you feel clever, but makes it harder and more time consuming for anyone else to understand what your code is doing, or verify that it's actually doing what it's supposed to.
I'm not sure how you could over-engineer code on a whiteboard? There isn't enough space. Instead you'd expect people to be extremely good at writing short and concise code which is still correct and simple enough for an interviewer to understand.
