I skipped ahead to "implementing a stack in python", which is a little weird because the stack class they implement is just a thin wrapper around lists with append aliased to push and "self.items[len(self.items)-1]" aliased to peek (note: in python you can just use negative indexing to access items near the end of a list)

This might seem pedantic, but, like, if the book isn't leveraging Python and it's not particularly clean code then I don't really understand what's on offer here.

I personally can get behind that argument. As an author you have to incentivize the reader to engage with what you've written, that's the job of the writer, not the reader. If you, in this way, alienate some users (like the one you replied to) so be it, this is also a choice of the author. I personally can't read `def fun(a,b): ...`, I strongly prefer `def fun(a, b): ...` and hence I stopped reading as well.

Personally I think the importance depends on the font face and particular letters used, and in your example it was entirely unimportant: I couldn't actually see the difference for a good while.

* PEP-8: This code is trying to demonstrate some pretty basic algorithms in simple terms. Should we care about double quotes versus single quotes and spaces to separate commas? If anything, this is an editorial issue in my opinion. Perhaps for your projects and production code you want it to be strictly PEP-8 compliant, but it does not diminish what is being presented here, which are examples of basic algorithms.

* Stack class is a thin wrapper: The author was built a stack class using common conventions. Some of it is pretty redundant, such as "def pop(self): return self.items.pop()", but the point remains. This is a clear and simple representation of an algorithms, focused on a common language. The fact that you can do stack-like things to a list misses the point of making a Stack class act and look like a stack. If anything, Python's list syntax makes implementing this minimalist.

* "The books provided on interactivepython.org are free and open source. They are for educational purposes." Perhaps the editing could be better. There are many ways to solve the same problem. At the end of the day this is given out for free and is a wealth of information.

You bring up a good point about editing and the value of free/open-source. I've been thinking about this often, recently. It's similar to the troubles plaguing news media. The propaganda may not be as malicious, but is similarly self-promoting, or promoting one's interests. Students have always suffered from bad textbooks, but before the internet we relied on professors to select good ones. Now we just have popularity and the vagaries of Google or upvotes on Hacker News. Of course, professors haven't always been great editors either.

Quick example of the "look and say" problem:

def look_and_say(n: int) -> str:

    s = '1'

    for _ in range(n - 1):

        s = ''.join(

            str(len(list(group))) + key

            for key, group in groupby(s))

    return s

That said, I think this might be what you're looking for: https://cs.uwaterloo.ca/~plragde/flaneries/FDS/

But there are to be the ways functional programmers solve the same task?

Thank you for the link.

In this book the author shows brute force, improved and functional implementations in python, c and haskell.

[1] http://www.parallel-algorithms-book.com [2] http://www.cs.cmu.edu/~15210

https://news.ycombinator.com/item?id=13854087

Queue and Deque could easily be developed from first principles by building on dictionaries or linked lists. It was a mistake to use list operations like s.pop(0) and s.insert(0, x).