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

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", and3 - "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 backgroundType 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 aboveP. 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.

It's not surprising that both authors have extensive training in mathematics! Contrary to what many may believe, mathematicians are generally among the very best technical writers--quite possibly, THE very best, as a rule! This book was obviously written with painstaking attention to detail. There are frequent cross-references, in both directions. Sometimes this is a bit of a nuisance, but it's probably unavoidable. I know of no other book on Python that rivals this one. The books by Mark Luzt (both of them!) and Naomi Cederare vastly inferior. The books by Lutz are far too long. The official Python website makes them redundant. And the book by Naomi Ceder is carelessly written. For example, I refer you to page 91. Towards the bottom of that page, immediately to the left of the displayed (in boldface type) comment "Obtains value for 'red'," there's an apparently extraneous and incorrect character "C." This kind of thing is unforgivable in a book on computer languages (or any natural language). In a mathematics book, some errors are tolerable because it knowledgeable reader can detect them--a priori. But in the sort of book under discussion here, the only way to determine whether an error was made is to run the code. That should not be necessary.

Its over a thousand pages long. I bought it to replace my previous reference bookon Python which is over 20 years old and out of date. I am an amateur Pythonprogrammer and sometimes forget how to type in some command. Even if I haveused that command before. It has a section on using pillow the image processingsoftware. I liked the unpack module which shows a better way of reading a binaryfile than what I have used before. I think the section on Tkinter could have beenbetter. Probably anything you want to know about Python is in this book. Its greatto have one book where you can find anything you need for programmingPython. Not cheap, but worth it if you are serious about Python programming.

The book is big and heavy, literally and topically. I am using it to freshen up on old python skills and see what is new.

I'm new to Python, but I am not new to programming - I recommend to all the old school people to toss learning BASIC / VisualBASIC and any variant of, for learning Python. This programming language is the replacement for BASIC.

Really good

This book is 1036 pages of bliss!! I love this book. It is exactly what I was wanting. Just flipping through it a little, I have learned a few things already and I only received it yesterday. It is well binded, well published and there is nothing superfluous written in it. Authors took great care in writing it. I really appreciate it. It is a total reference. I will prob order the javascript book that is just like it.Very very handy reference book.. I'm very impressed.. Worth every penny.. I also bought Python Distilled. For me personally, I like this book much better. It is a much better reference than P.D.

My background is in statistics and I learnt programming (R) because I wanted to implement statistical algorithms. I have tried to learn programming in general (C, C++, Python) from many books but I always 1. either get bored with the numerous tedious examples of the same language concept or 2. get overwhelmed with technical explanations of concepts that are not necessarily that difficult to understand. I randomly stumbled across this book on Amazon. Finally, a lot of the behaviors that I thought were strange in Python make sense! This book explains well the concepts behind Python data structures esp. mutable v. immutable objects.