Scan barcode
alexander0's review against another edition
4.0
This book is very good! If you want to teach yourself Python from a very basic level, this book is the way to start. There are others out there, but they probably won't be as simple and pedagogically thorough. This book is NOT a "theory, theory, theory, then practice" book. This is a "Just do this; okay, now in detail, what did you do? If that was fun, do these other things..." book. It works very well! If you ever have a month where you have a couple hours everyday, you will be done with this in no time, and feel much better for it.
chentao's review against another edition
3.0
I wanted to bridge the gaps in my Python knowledge.
The concept of OOP always puzzles me. Coming from a FORTRAN background, I am very used to functional programming.
However, I found that until exercise 40, the pace of the book is very elementary-level. But from ex43, the pace is suddenly the speed of light. I am again, not surprisingly, lost in the world of class, objects, inheritance, instance, constructor, ... I found the book can do a better job by extending it's content from ex43.
The concept of OOP always puzzles me. Coming from a FORTRAN background, I am very used to functional programming.
However, I found that until exercise 40, the pace of the book is very elementary-level. But from ex43, the pace is suddenly the speed of light. I am again, not surprisingly, lost in the world of class, objects, inheritance, instance, constructor, ... I found the book can do a better job by extending it's content from ex43.
bonfire_at_night's review against another edition
4.0
Shaw describes the goal of his book thus: "When you're done, you'll be a reasonably competent Python beginner. You'll still need to go through a few more books and write a couple more projects, but you’ll have the skills to complete them. The only thing in your way will be time, motivation, and resources."
A Beginner's Guide to Python Programming
Learn Python the Hard Way is a great textbook for absolute beginners. Ironically, until far into the book the exercises are quite easy when compared to similar books. In his Learn C the Hard Way, what made learning so hard was the aspiration to write software that satisfies strict standards of security, and that certainly is no easy task. There is nothing comparable in this book.
Finishing the book actually is not as big a deal as for many other textbooks in software development. Personally, it took me about three or four weeks. Granted, I already knew most concepts, but I think even complete beginners can work their way through in a couple of weeks tops.
What I liked was that it doesn't bore the reader with tedious information you will pick up along the way anyway. For instance, stuff like "what variable names are permissible" is reduced to the bare minimum, rather than having lengthy exercises on that issue (like you actually find in other introductions).
But still the Hard Way?
I think Shaw considers his approach to learning to be "The Hard Way", because he simulates the programmer's everyday life - an experience that can be quite frustrating.
For one thing, he over and over emphasizes the importance of typing in code by hand (rather than copying it). This obviously can get tedious, especially with the significantly longer examples towards the end of the book. I've found it surprising how much you learn from this, if you can keep to the point while doing so. It may also be a good occasion to gain familiarity with Vim or another tool of choice.
Often he lets you type in certain constructions without telling you what they do (like for if instructions or the loops). Once you see the output, their functionality becomes obvious. A full-fetched explanation may have been daunting or even intimidating, now it's easy and no big deal. And there really aren't too many constructions you have to learn. So, the hard way may turn out to be the easier way.
As exercises, you are made to look up many concepts yourself. For instance, you are asked to look for methods you can invoke on lists. At a later chapter, there is an exercise in which you have to read up on what object-oriented programming is, including the ideas of objects and classes. In this case, I liked the approach. When you are given an idea of what there is, you can find much information on the concepts. While reading online documentations can be frustrating for beginners, you should give it a good go. It will give you a sense of achievement when you found something yourself and afterwards you know much more than you did before.
At one point, it gets really quite silly, though. Chapter 37 gives a list of all Python keywords and asks of the reader to go on only when she/he knows what it does. It doesn't explain the keywords at all; it only mentions them, so that you can look them up online. I suppose the idea is to convey a real feeling of being a programmer, where you constantly come upon things you don't understand and you then have to look for them with the help of a search engine. Still, the idea of reading a textbook is to be ahead of that, at least in regard to the basic stuff.
Towards the end, probably around chapter 40 (of 52), the exercises get significantly tougher. At first, writing tests is quite simple (to get an idea of what it means to write such tests), but getting the website to run as it it's supposed to do (not to mention the final exam), that's quite challenging! I think the idea that it doesn't take you by the hand to go through is one reason why you really feel the hard way here.
Unfortunately, I feel like you still won't get much practice from finishing this book. Every chapter is called an "Exercise" and you do type in code, but the Study Drills are usually quite short and simple. I've found more complex and independent exercises in other books more helpful. So, you should begin to write little projects to check whether you are really able to apply the concepts introduced in each exercise.
Pep Talk from an otherwise demanding Tutor
The book is written in a style that mirrors natural conversation. The tone is friendly but demanding. Expect drill ("Shut up and type all this in") as well as rebuke ("I've already told you, keep up!"). But there is also advice to take a closer look ("There’s actually quite a lot of information in this little function, so it would be good for you to study it") or even to take it slow sometimes ("Take a break right now and try playing with these two concepts before continuing").
Shawn also eliminates false assumptions the reader may have, as when pointing out that programmers are no math geniuses (even if some pretend they were), that programmers make a lot of mistakes and that even experienced programmers get intimidated by beginning complex projects. I find it refreshing to be reminded of these things from time to time.
Learn to Speak like a Programmer
What I loved about the book was how it teaches you to speak properly. This may sound silly, as programming languages obviously are not spoken, at least not like natural languages. However, You do talk about code.
Did you ever feel that math is full of odd phrasing, like "Let f be the function...", "f takes the value y for argument x" or "universe of discourse" (to only mention two of many examples)? I think programming is similar in this respect. The language used in tutorials or personal conversation in this area can be quite esoteric and daunting to the newbie. To a certain degree Shaw tries to prepare you for that.
For instance, in one exercise he makes you create a list of all commonly encountered symbols, name them, and memorize them. It's a boring task, but learning vocabulary like this obviously will be necessary to verbally talk about your code. He also introduces more technical computer-science notions, occasionally sugar-coated in a mockery of jargon. As when he writes: "That concept is called 'instantiate,' which is just a fancy, obnoxious, overly smart way to say 'create.'"
Moreover, it's necessary to pick up a certain stock of concepts used to describe and analyze programming languages. This is also very similar to math, where formal expressions represent a world of mathematical objects. I loved the no bullsh*t approach that the book takes here.
For instance, in Chapter 41 you get a simple, no-jargon definition of all the ideas you need to read and write code in accordance with the object-oriented paradigm. Like "is-a—A phrase to say that something inherits from another, as in a “salmon” is-a “fish.” or "class—Tell Python to make a new kind of thing", to mention only two examples. There are also attempts to translate code into English: "You have to be able to say the sentence exactly the same every time whenever you see that form. Not sort of the same, but exactly the same."
Object-Oriented Programming
Talking of object-oriented programming, the paradigm takes a rather central place in the book (as is common for Python), though Shaw's stance seems to be rather critical.
To be honest, I didn't really like how the book approaches the issue. Shaw introduces objects, classes, and instantiation by comparison to dictionaries and modules. In all those cases you have some thing out of which you get another thing. However, the things you get out are different; the way you get things out are different; and the things from which you get things out are not very similar, either. You get a thing (data of any type) out of a dictionary by specifying a key; you get a thing (function or variable) out of a module by dot notation; and you get things out of classes by instantiating them and then refer to the properties and methods of objects by dot notation.
Maybe it's because of my background in philosophy, but I feel like introducing the concepts just in the way they were intended is much less confusing. There are things (circles, human beings, cars, whatever); things can be of different types, and the types (or classes) are defined by specifying characteristic properties and activities (or methods). When you create an object, you mentions its type. That's it. I think that is more straight-forward then thinking about the similarities and differences to the other concepts, familiar as they may be at that point.
To be honest, I don't really see where Shaw's hostility towards OOP comes from. You find passages like: "Search online for 'object-oriented programming' and try to overflow your brain with what you read. Don’t worry if it makes absolutely no sense to you. Half of that stuff makes no sense to me either." He may be right, so I'm genuinely interested in his arguments.
In any way, generally it's a very good introduction to Python that takes an approach quite different from what you would find in other textbooks. For the most part, the approach worked for me.
Rating: 4/5
A Beginner's Guide to Python Programming
Learn Python the Hard Way is a great textbook for absolute beginners. Ironically, until far into the book the exercises are quite easy when compared to similar books. In his Learn C the Hard Way, what made learning so hard was the aspiration to write software that satisfies strict standards of security, and that certainly is no easy task. There is nothing comparable in this book.
Finishing the book actually is not as big a deal as for many other textbooks in software development. Personally, it took me about three or four weeks. Granted, I already knew most concepts, but I think even complete beginners can work their way through in a couple of weeks tops.
What I liked was that it doesn't bore the reader with tedious information you will pick up along the way anyway. For instance, stuff like "what variable names are permissible" is reduced to the bare minimum, rather than having lengthy exercises on that issue (like you actually find in other introductions).
But still the Hard Way?
I think Shaw considers his approach to learning to be "The Hard Way", because he simulates the programmer's everyday life - an experience that can be quite frustrating.
For one thing, he over and over emphasizes the importance of typing in code by hand (rather than copying it). This obviously can get tedious, especially with the significantly longer examples towards the end of the book. I've found it surprising how much you learn from this, if you can keep to the point while doing so. It may also be a good occasion to gain familiarity with Vim or another tool of choice.
Often he lets you type in certain constructions without telling you what they do (like for if instructions or the loops). Once you see the output, their functionality becomes obvious. A full-fetched explanation may have been daunting or even intimidating, now it's easy and no big deal. And there really aren't too many constructions you have to learn. So, the hard way may turn out to be the easier way.
As exercises, you are made to look up many concepts yourself. For instance, you are asked to look for methods you can invoke on lists. At a later chapter, there is an exercise in which you have to read up on what object-oriented programming is, including the ideas of objects and classes. In this case, I liked the approach. When you are given an idea of what there is, you can find much information on the concepts. While reading online documentations can be frustrating for beginners, you should give it a good go. It will give you a sense of achievement when you found something yourself and afterwards you know much more than you did before.
At one point, it gets really quite silly, though. Chapter 37 gives a list of all Python keywords and asks of the reader to go on only when she/he knows what it does. It doesn't explain the keywords at all; it only mentions them, so that you can look them up online. I suppose the idea is to convey a real feeling of being a programmer, where you constantly come upon things you don't understand and you then have to look for them with the help of a search engine. Still, the idea of reading a textbook is to be ahead of that, at least in regard to the basic stuff.
Towards the end, probably around chapter 40 (of 52), the exercises get significantly tougher. At first, writing tests is quite simple (to get an idea of what it means to write such tests), but getting the website to run as it it's supposed to do (not to mention the final exam), that's quite challenging! I think the idea that it doesn't take you by the hand to go through is one reason why you really feel the hard way here.
Unfortunately, I feel like you still won't get much practice from finishing this book. Every chapter is called an "Exercise" and you do type in code, but the Study Drills are usually quite short and simple. I've found more complex and independent exercises in other books more helpful. So, you should begin to write little projects to check whether you are really able to apply the concepts introduced in each exercise.
Pep Talk from an otherwise demanding Tutor
The book is written in a style that mirrors natural conversation. The tone is friendly but demanding. Expect drill ("Shut up and type all this in") as well as rebuke ("I've already told you, keep up!"). But there is also advice to take a closer look ("There’s actually quite a lot of information in this little function, so it would be good for you to study it") or even to take it slow sometimes ("Take a break right now and try playing with these two concepts before continuing").
Shawn also eliminates false assumptions the reader may have, as when pointing out that programmers are no math geniuses (even if some pretend they were), that programmers make a lot of mistakes and that even experienced programmers get intimidated by beginning complex projects. I find it refreshing to be reminded of these things from time to time.
Learn to Speak like a Programmer
What I loved about the book was how it teaches you to speak properly. This may sound silly, as programming languages obviously are not spoken, at least not like natural languages. However, You do talk about code.
Did you ever feel that math is full of odd phrasing, like "Let f be the function...", "f takes the value y for argument x" or "universe of discourse" (to only mention two of many examples)? I think programming is similar in this respect. The language used in tutorials or personal conversation in this area can be quite esoteric and daunting to the newbie. To a certain degree Shaw tries to prepare you for that.
For instance, in one exercise he makes you create a list of all commonly encountered symbols, name them, and memorize them. It's a boring task, but learning vocabulary like this obviously will be necessary to verbally talk about your code. He also introduces more technical computer-science notions, occasionally sugar-coated in a mockery of jargon. As when he writes: "That concept is called 'instantiate,' which is just a fancy, obnoxious, overly smart way to say 'create.'"
Moreover, it's necessary to pick up a certain stock of concepts used to describe and analyze programming languages. This is also very similar to math, where formal expressions represent a world of mathematical objects. I loved the no bullsh*t approach that the book takes here.
For instance, in Chapter 41 you get a simple, no-jargon definition of all the ideas you need to read and write code in accordance with the object-oriented paradigm. Like "is-a—A phrase to say that something inherits from another, as in a “salmon” is-a “fish.” or "class—Tell Python to make a new kind of thing", to mention only two examples. There are also attempts to translate code into English: "You have to be able to say the sentence exactly the same every time whenever you see that form. Not sort of the same, but exactly the same."
Object-Oriented Programming
Talking of object-oriented programming, the paradigm takes a rather central place in the book (as is common for Python), though Shaw's stance seems to be rather critical.
To be honest, I didn't really like how the book approaches the issue. Shaw introduces objects, classes, and instantiation by comparison to dictionaries and modules. In all those cases you have some thing out of which you get another thing. However, the things you get out are different; the way you get things out are different; and the things from which you get things out are not very similar, either. You get a thing (data of any type) out of a dictionary by specifying a key; you get a thing (function or variable) out of a module by dot notation; and you get things out of classes by instantiating them and then refer to the properties and methods of objects by dot notation.
Maybe it's because of my background in philosophy, but I feel like introducing the concepts just in the way they were intended is much less confusing. There are things (circles, human beings, cars, whatever); things can be of different types, and the types (or classes) are defined by specifying characteristic properties and activities (or methods). When you create an object, you mentions its type. That's it. I think that is more straight-forward then thinking about the similarities and differences to the other concepts, familiar as they may be at that point.
To be honest, I don't really see where Shaw's hostility towards OOP comes from. You find passages like: "Search online for 'object-oriented programming' and try to overflow your brain with what you read. Don’t worry if it makes absolutely no sense to you. Half of that stuff makes no sense to me either." He may be right, so I'm genuinely interested in his arguments.
In any way, generally it's a very good introduction to Python that takes an approach quite different from what you would find in other textbooks. For the most part, the approach worked for me.
Rating: 4/5
larry1138's review against another edition
4.0
This book is great up until the later exercises when the learning curve gets extremely difficult, and even with drilling I feel like I wasn't prepared to continue on. Nevertheless, this book did exactly what I wanted it to do: provide a good solid introduction to Python and programming in general. Plus it has a handy command line crash course at the end. I look forward to exploring other programming books that go more in depth with the language, with perhaps a better learning curve, such as Python Crash Course by Eric Matthes and Automate the Boring Stuff by Al Sweigart. Shoutout to Zed Shaw for giving me a better programming introduction in one book than 1.5 years of university classes.
Zed also makes you use the Atom IDE, which quite frankly is the quickest, cleanest, beginner-friendly IDE I've ever used besides maybe Notepad++ which is hilarious. Highly recommend Atom! atom.io for download!
Zed also makes you use the Atom IDE, which quite frankly is the quickest, cleanest, beginner-friendly IDE I've ever used besides maybe Notepad++ which is hilarious. Highly recommend Atom! atom.io for download!
sabin's review against another edition
4.0
A funny and informative introduction for complete beginners in Python, or even complete beginners in programming. The exercises can get tedious at times; I knew most of the stuff explained in here, it consists mostly of good practices and programming concepts, and they're exemplified using Python. The issue I had with the book was that at times things are not thoroughly explained, probably because the target audience consists of beginners and the author wanted to keep it as simple as possible. Still, I learned a few (basic) things about OOP reading this, it was fun. I'm looking forward to the next book in the series. Recommended for complete beginners, but be prepared to learn some extra stuff, like CLI. Oh, and I loved that Zed hates IDEs, like most good programmers do.
More...