Book Review: Effective Python: 59 Specific Ways To Write Better Python 71
MassDosage writes: If you are familiar with the "Effective" style of books then you probably already know how this book is structured. If not here's a quick primer: the book consists of a number of small sections each of which focus on a specific problem, issue or idea and these are discussed in a "here's the best way to do X" manner. These sections are grouped into related chapters but can be read in pretty much any order and generally don't depend on each other (and when they do this will be called out in the text). The idea is that you can read the book from cover to cover if you want but you can also just dip in and out and read only the sections that are of interest to you. This also means that you can use the book as a reference in future when you inevitably forget the details or want to double check something. Read below for the rest of Mass Dosage's review.
Effective Python stays true to this ethos and delivers 59 (not 60, nope, not 55) but 59 specific ways to write better Python. These are logically grouped into chapters covering broader conceptual topics like "Pythonic thinking", general technical features like "Concurrency and parallelism" as well as nitty gritty language details like "Meta classes and attributes". The range of topics is excellent and cover relevant aspects of the language that I'd imagine pretty much any developer will encounter at some point while developing Python programs. Even though there is no required order to reading the various sections if you want to read the book from cover to cover it's organized in such a way that you can do this. It starts off with getting your head around coding in Python before moving on to specifics of the language and then ending with advice on collaboration and setting up and running Python programs in production environments.
| Effective Python: 59 Specific Ways To Write Better Python | |
| author | Brett Slatkin |
| pages | 227 |
| publisher | Addison-Wesley |
| rating | 9/10 |
| reviewer | Mass Dosage |
| ISBN | 978-0-13-403428-7 |
| summary | helps you harness the full power of Python to write exceptionally robust, efficient, maintainable, and well-performing code. |
I really enjoyed the author's approach to each of the topics covered. He explains each item in a very thorough and considered manner with plenty of detail but manages to do this while still being clear and concise. Where relevant he describes multiple ways of achieving a goal while contrasting the pros and cons of various alternative solutions, ending off with what he considers the preferred approach. The reader can then make up their own mind based on the various options which applies best in a given situation instead of just being given one solution. The author clearly understand the internals of the Python language and the philosophy behind some of the design decisions that have resulted in certain features. This means that instead of just offering a solution he also gives you the context and reasoning behind things which I found made it a lot easier to understand. The discussions and reasoning feel balanced and informed by the experience of a developer who has been doing this "in the trenches" for years as opposed to someone in an ivory tower issuing dictates which sound good in theory but don't actually work in the real world. The vast majority of the topics are illustrated through code samples which are built on and modified at each stage along the way to a final solution. This gives the reader something practical they can take away and use and experiment with and clearly shows how something is done. The code samples are easily comprehensible with just enough code to demonstrate a point but not so much that you get distracted by unnecessary additions.
While most of the topics are Python specific plenty of the best practices and advice apply equally well to other programming languages. For example in one section the author recommends resisting some of the brevity offered by the Python where this can lead to unreadable code that is hard to understand but the same could be said of writing code in many other languages (I'm looking at you, Perl). This also applies to a section related to choosing the best data structure for the problem at hand — if you end up nesting Maps within Maps in your code then you're probably doing something wrong regardless of the language. Still, the main focus here is Python and the author does not shy away from going deep into technical details so you'll definitely need some knowledge of the language and ideally some experience using it in order to get the most out of it.
Effective Python is not a book for complete newbies to Python and I think it's suited more to intermediate users of the language wanting to take their skills to the next level or advanced programmers who might need some fresh takes on the way they do things. The subjects and opinions in this book could either convince you to do something differently or reassure you of the reasons why you're already doing things a certain way (external affirmation that you're right is also useful at times!) I'm no Python expert but I found the book drew me in and kept my attention and I certainly learnt a lot which will come in handy the next time I put on my Pythonista hat and do some Python coding. Highly recommended.
You can purchase Effective Python: 59 Specific Ways to Write Better Python from amazon.com. Slashdot welcomes readers' book reviews (sci-fi included) -- to see your own review here, read the book review guidelines, then visit the submission page. If you'd like to see what books we have available from our review library please let us know.
Books. Heh. (Score:1)
It always makes me giggle whenever this "tech" site publishes a review of something static and made of dead trees.
How about firing up some reviews of blogs for people who like to keep up with emerging tech instead?
Re: (Score:2)
You assume that books cannot change, but books kept in an electronic format can, and do, receive updates.
Especially when your provider is threatened with a lawsuit of some kind and they pull it from your account.
Re: (Score:1)
I know what you mean.
It always makes me giggle whenever someone comments on this "tech" site and exposes a laughably narrow and counterproductive view of programming tools, computers, or anything else related to technology.
Re: (Score:2)
Did you stop giggling when you found out it's an e-book?
Re: (Score:2)
You know, perl programmers never say anything quite as inane as this.
Re: (Score:2)
Or COBOL ones. Mind you, most of them don't know what interwebs are so you're unlikely to ever meet one unless you walk into a pub and there's a Fairport Convention tribute band playing.
Re: (Score:2)
Hey COBOL is awesome, especially the SCREEN SECTION :)
Why futz about with (n)curses for a day when you can knock out a beautifully laid out text UI in a 10 minutes!
(I'm 50% serious here..)
Re: (Score:2)
That's interesting. Enjoy your giggles. I've got one screen, and if I'm programming, that's what I want to use it for. I find a book doesn't shove my program into the background, cover it up, and attempt to hide it. And this is even without using something that trys to pretend that the front application is the only one I could possibly be interested in seeing.
Re:F*ck Python (Syntax Squabbles & Choice) (Score:1)
I'd like to give Microsoft rare kudos for making a language that (mostly) allows two syntax styles: "C" and "VB". Maybe they can add a third: Python/Ruby-like. (I know their CLR allows many languages, but they are not quite as cross-comparable as C# and VB.Net.)
Everybody has their syntax preference and there is no use in continued bickering; it's a personal thing that matches personal psychology/physiology. Your head is not my head. Your fingers are not my fingers.
My fingers are getting old, and I'm beginni
Effective Python (Score:2)
Hisssssss
Re: (Score:2)
Re:yeah right (Score:4, Informative)
Every tool has it's place and Python is no different.
Does Python get used where it's not the best tool? Obviously. But it's a failing of the programmer/system engineer, not the tool. There is a lot of stuff a tool can do. You can flatten a 10" wide plank on both sides and make it perfectly square using a crescent wrench and insert a screw with a hammer, but you are either going to waste a lot of time, end up with substandard results, or both...
Re: (Score:3)
You can compile Python into C. I had a Python script to roll a pair of dice one million times that took 123 seconds. Compiled Python to C, it took four seconds.
http://cython.org/ [cython.org]
Re: (Score:3)
I haven't tried running craps on my Nvidia video card yet. That should be a hell of a lot faster.
https://developer.nvidia.com/how-to-cuda-python [nvidia.com]
Re: (Score:2)
You can compile Python into C. I had a Python script to roll a pair of dice one million times that took 123 seconds. Compiled Python to C, it took four seconds.
Great. However, all of Python's weaknesses exist to support its use as an interpreted language. There are things I really love about Python (eg list comprehensions look almost mathematical, and are designed for readability), but just compiling it doesn't get round the limitations of the language architecture.
Re: (Score:2)
However, all of Python's weaknesses exist to support its use as an interpreted language.
This reminds of the arguments made against Java when it first came out 20 years ago: "It compiles to a virtual machine, not into actual assembly code like C/C++ does. That's a serious limitation for a programming language."
Re: (Score:2)
That's a different issue. There's a discussion about whether there is such a thing as "interpreted languages" and "compiled languages", and in the strictest sense, the answer is no, because some normally-compiled languages can be run in an interpreter, and most normally-interpreted languages can be compiled; but there is also a philosophical debate that allows an imprecise use of the terms. Java is what I'd consider a "compiled language" because of its architectural design -- I don't care that the target ar
Re:yeah right (Score:4, Insightful)
STFU, Python shill. Python has no place. Compiled languages are the ONLY way to go if you want to get any big boy work done.
BTW, this Python shill actually HATES Python for a number of structural reasons and I avoid it for most tasks. It doesn't seem to be the proper tool for the kind of work I generally do, but that doesn't mean it doesn't have its use. A good programmer has many tools and understands which ones to use for what task.
Re: (Score:2)
So what do you suggest?
Bash and grep?
perl?
This is /. Everything is to be written in elisp and run under Emacs.
Re: (Score:2)
Python is a useful language for prototyping things, or trying out some new algorithm.
It allows me to test these things out without worrying about all kinds of details like I would if I were programming in C.
Of course if I want performance for whatever it is I'm doing, then yes, I'll rewrite in C eventually.
And yet you don't need to be able to dynamically rewrite entire class definitions in order to do most of the useful stuff that Python lets you do quickly. And if you do use a lot of the stuff that makes Python Python, it will be a tough job to rewrite into C at a later date. As such, I personally feel that Python is a double-edged sword, and I would like the core of it without the ultra-dynamic, self-modifying stuff that (for my purposes) only serves as a source of potential errors.
Re: (Score:2)
Re: (Score:3)
people being afraid to touch the code to avoid breaking a rare and poorly-tested code path
In short, no unit tests were ever written.
Unit tests are cool. (Score:2)
Just write 'em along with your code. It's easy in general, and in Python, it's even easier. Between the diff import lib and the unittest import lib, you should be able to do *something* about testing.
Re: (Score:2)
people being afraid to touch the code to avoid breaking a rare and poorly-tested code path
In short, no unit tests were ever written.
Yes, welcome to the real world of software development where deadlines trump other things.
Your concept of the "real world" is pretty damned narrow... and false.
I would reply like this: No. Welcome to the real world where shitty programmers or shitty organizations pretend their shitty practices are the general case.
I've worked in large commercial firms, small start-ups and defense-related companies, each with teams of various sizes and different projects. C/C++, Java, C#, Python and what not. Some where horrid, some were great. Most were ok. Unit testing has always been the norm for the ok an
Re: (Score:2)
people being afraid to touch the code to avoid breaking a rare and poorly-tested code path
In short, no unit tests were ever written.
Yes, welcome to the real world of software development where deadlines trump other things.
Like I said (assuming you're the original AC), you need to work with better engineers. Code that's hard to test is typically a poorly designed monolith. People that "don't have time" to write tests code themselves into corners and then try to write the tests after the fact. Type checking doesn't prevent that, it just makes it harder to refactor.
Re: (Score:2, Funny)
I see that insecure python fanboys are downmodding this thread like a herd of global interpreter locks. I guess there's little chance for intelligent (if slightly heated) discussion of the merits of the language.
Re: (Score:2, Insightful)
The best way to write Python is not to write it at all. Everywhere I've worked, any large project written in a dynamically typed language ballooned into a maintenance nightmare, sometimes to the point of people being afraid to touch the code to avoid breaking a rare and poorly-tested code path.
Seriously, it boggles the mind that, after all academic research and technical progress in compiler development, we still use dynamic languages. A compiler works like a mathematical proof machine, doubly so when a type-inferenced language is used. This is a tremendous advantage for error-checking and program correctness, yet it's "cool and hip" to take the hard way. Dynamic languages, python included, make easy things trivial, and hard things impossible. It's a tradeoff that should never be made.
I write python for a living, and I'm with you on dynamically typed languages, for big projects.
Having said that, small to medium projects and prototyping python is fantastic. Python lets me get a project up and running, without all the boilerplate and unnecessary overhead, which allows me to concentrate on getting the algorithm correct.
Then, if need be, I port to a language like Java (or C++ or C or w/ever).
Re: (Score:1)
I write python for a living, and I'm with you on dynamically typed languages, for big projects.
Having said that, small to medium projects and prototyping python is fantastic. Python lets me get a project up and running, without all the boilerplate and unnecessary overhead, which allows me to concentrate on getting the algorithm correct.
Then, if need be, I port to a language like Java (or C++ or C or w/ever).
True, but the problem emerges when a small project grows in size and scope, as it eventually will. Then a herd of outsourced developers or overenthusiastic and underexperienced co-ops take over, while the original developer leaves. Then all hell breaks loose. Even small projects need to be started on solid foundations. With modern compiled languages the barrier to start a project should be no worse than starting with a dynamic language. The decision will always pay off in the long run.
Re: (Score:2)
The best way to write Python is not to write it at all. Everywhere I've worked, any large project written in a dynamically typed language ballooned into a maintenance nightmare, sometimes to the point of people being afraid to touch the code to avoid breaking a rare and poorly-tested code path.
Seriously, it boggles the mind that, after all academic research and technical progress in compiler development, we still use dynamic languages. A compiler works like a mathematical proof machine, doubly so when a type-inferenced language is used. This is a tremendous advantage for error-checking and program correctness, yet it's "cool and hip" to take the hard way. Dynamic languages, python included, make easy things trivial, and hard things impossible. It's a tradeoff that should never be made.
Python is not the problem, bad engineering practices are. Strict typing is not a "mathematical proof machine", it's a spell checker. You can still write utter and complete garbage. Seriously, if you don't have good unit testing, functional testing and static code analysis, you are likely creating a support nightmare. And if you do have good unit testing, functional testing and static code analysis then strict typing is a hinderance to good design.
You need to work with better engineers.
My Python is Already Effective (Score:1)
Re: (Score:1)
but your GF says it has white-space errors
59 Ways? (Score:2)
My 60th way to write better python (Score:2)
alias python=gcc
Re: (Score:2)
Classy.
Rule #1 (Score:2)
Just kidding!