The book introduction addresses 3 types of individuals:

1 - "Beginner programmer or a newcomer with basic knowledge of another programming language",
2 - "Good at programming and want to ... transition ... to Python", and
3 - "Experienced Python programmers".

With that in mind, I'll give my impression by topics:

1) Overall impression ("TL;DR")

Great for type 2. May serve type 1 people that learn by examples and frown upon theory. Type 3 may want to look only into specific chapters.

2) Reasoning for each person background

Type 1 people with serious interest in programming should read better introductions to programming first and, especially (IMO), data structures, how the CPU works (minimally) etc. I'm one of those who suggest learning programming with C. Surely you can start with Python, but beware when doing it with this book.

The classic case is you learning by example, and then losing a long time fixing your deficiencies in collections, what makes a collection ordered, hashsets, equality and so on. You are going to do wrong things that could be avoided IMO. If you learn by example, and want to get started quickly, then I guess the book works.

Type 2: great. The entire book is useful. I feel like having a conversation, writing down my notes, disagreeing with some things, correcting others, and learning a lot from all the content.

Type 3: whatever you're missing is probably not inside this large book. It is probably in Stackoverflow or deep down the online documentation of Django, django-rest-framework, cryptography, mathplot, tk or whatever etc. Perhaps you may benefit from Parallel Programming, Networks (if you never did lower level like sockets), and of course Scientific Programming. You will skip most of this book I presume.

3) Specific points for what I said above

P. 105: I seriously disagree with teaching the technical concept only to say you're going to relax your language for the sake of easiness. In short, when you introduce a concept, use it consistently. I think everyone, _especially_ beginners, should always try to enforce their own correct usage of technical concepts. This is not pedantic... when you search online, using the proper technical term for your doubt will help you get the information much quicker (increase accuracy of results - accuracy in the statistical sense).

P. 106: Dynamically vs statically typed and all that should have been mentioned briefly.

P. 159: He should have emphasized ordering vs not ordering of particular collection types.

P. 171: typo. Subsection 12.3.5 should have been 12.3.4.1 or, better yet, an unordered subsection. Especially because he refers to this subsection later in page 321 as "12.3.4".

P. 258: The book does not mention the deprecation of utcnow() because it was edited before Python 3.12. Nevertheless, you should know.

P. 267: there is an example for calculating time differences with different TZs. I'd wish he had commented on the expected outcome if comparing with the same TZ since it is not immediately clear (to me) what the expected (but wrong) result would be.

P. 287: keyword only arguments. While the example is not solely focused on keyword only arguments, it is shown directly below a paragraph about this, and one is forgiven for finishing the paragraph and look at the code as an example of kw only arguments. I'd exemplify with (*, a, b, ...) instead of (a, b, *, d, e).

P. 370: I think he should have said that it is, at the very least, generally considered more elegant to call class members from the class name instead of from the instance.

P. 379: I know he meant the discussion of hash and equality as a sidenote, hence the "Note", but this is such a common pitfall in so many languages that I believe he should have clearly stated all expected requirements of Python from __hash__ and __eq__ methods considered together. This is certainly one of the first minefields a beginner will encounter. I also believe a nice introduction to pigeonhole and collisions could have been there, or at least mentioned so the reader could look it up online. This would help understand why unequals MAY, while equals MUST, have the same hash, and, conversely, why different hashes MUST, while same hashes MAY (very rarely do), correspond to different objects. And thus why when you define one you are very strongly advised to define the other.

P. 474: type aliases. Using built in types is allowed since Python 3.9 and it must have been stated in the book.

P. 474: type unions. Considering it is allowed since 3.10 as stated in the book, I believe the section should have focused on the new way instead of "amending" the book to mention the new behavior in what feels like an afterthought.

P. 519: it is dangerous, IMHO, to say MD5 has "limited" suitability for passwords when you're not fully discussing the matter. I'd say "never unless you clearly understand the security of hashes". In short, for a book like this, "never with an asterisk" is more appropriate (again, IMHO).

Chapter 32: I understand the mindset, but JSON should open this chapter instead of XML. I mean, c'mon, it is year 2024 already.

P. 652: typo. Footnote has original German "die" instead of "the [database]".

P. 654: typo. SQL example has a period instead of underscore in "SELECT warehouse.compartment.number" (last period).

P. 713. I know. Someone out there still uses it. But why spend all that paper on FTP when many other more pressing needs are referred to an online documentation?

P. 917. The explanation on Django template folder structure is not clear. We all know it avoids ambiguity, but the less known information is _how_ Django's merging of templates would create ambiguity. The book should have seized the opportunity, as it creates a much stronger argument for what is an apparent nonsensical design that so many newcomers complain about.

Brand	N/A
Rating	4.7 (124 ratings)
Price	$50.5
Category	Software

Python 3: The Comprehensive Guide to Hands-On Python Programming (Rheinwerk Computing)