Slashdot Mirror
Book Review: Effective Python: 59 Specific Ways To Write Better Python
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: 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.
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.
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.
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.
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?
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.
Love sees no species.
Goddamn whitespace errors!
Hisssssss
#!/usr/bin/perl
is the best way to start writing better python.
heh heh heh
Don't!
Why? Other than; it's hard?
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...
"File to fit, pound to insert, paint to match" - Aircraft Maintenance 101
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.
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 beginning the like the VB (Net) style because I don't have to keep pressing the damned shift key as much. (There are other smaller reasons, but I won't go into them here.)
Table-ized A.I.
I see your point. Makes perfect sense now.
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.
pretty much.
its amazing how much people think they can do without writing any tests.
what a great trap, you can say its 'done' in a quarter the time, except it never quite works properly, and
at that point you have no latitude to go in and fix it
Or, when they're books about Ruby on Rails...
I pre-ordered Agile Development in Rails, when Rails 2.3 was just coming out. By the time the book arrived, I'd already received about 100 pages of addendums that superseded the printed copy I ordered, because changes to Rails had invalidated the book before it even hit the presses.
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.
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/
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.
Did you stop giggling when you found out it's an e-book?
"I like to lick butts!" by MobileTatsu-NJG (#32700246) (Score:5, Informative)
I guess the truth hurts enough to waste their modpoints on it.
How would this be different for any other language then?
Would you feel more comfortable breaking some C code or C++?
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).
So what do you suggest?
Bash and grep?
perl?
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.
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.
"Every tool has it's place"
The apostrophe has its place. That wasn't it.
It always amazes me that people who claim to know so many computer languages seem unable to grasp that it's means it is.
It amazes me when people get all worked up over a typo''''''''
So what do you suggest?
Bash and grep?
perl?
This is /. Everything is to be written in elisp and run under Emacs.
You know, perl programmers never say anything quite as inane as this.
What, 59 ways? With python it should just be *one* way. (And if you're going for clickbait it should be *69* ways.)
alias python=gcc
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
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.
I think we've pushed this "anyone can grow up to be president" thing too far.
groovy
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.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
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.
"File to fit, pound to insert, paint to match" - Aircraft Maintenance 101
Craps faster.. Great...
Anybody doing repetitive math computations in Python is in trouble. Any interpretive language is in the same boat...
> compiled languages
You keep using that word, but I don't think it means what you think it does.
You can compile python.
Just because a language is compiled doesn't mean it has strict typing, or static typing.
Start with an actual design you goddamn python script-kiddies. :-)
Just kidding!
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
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.
What if you don't have skilled and experienced devs to protoype stuff because you micromanaged them out of the office and won't pay enough to hire another?
This isn't about a well run and funded shop looking to the future. It's about barely scraping by ones trying to get the next gasp of air before they fold. In short, shitty good enough beats good for the same reasons poor people get payday loans. It's their only option.
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..)
Yeah, cause no bad code was ever written in Java.
I say always use the right tool for the job.
That said, I'm not sure there is a case where python is the right tool.
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.
Premature optimisation never pays off.
The worst Java code is 100x more maintainable than good python code.
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.
I've fallen off your lawn, and I can't get up.
Uhhhhh. Nope.
You've either never written/read good python or have never read less than stellar java.
Considering the layout of keyboards, it's unlikely it is a typo.
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.
Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
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.
Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
I think you mean a type *
Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
They can't monetize blog affiliation nearly as well as books. Check the link... tag=slashdot0c-20 ... that's an amazon affiliate account. Slashdot gets a 6-8% cut on all the sales through that link.
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."
So which python does the book talk about, 2 that everyone uses, or 3 that hasn't caught on?
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 architecture is rarely seen in hardware form. The limitation this leaves you with is execution speed, which was a genuine concern in the early days of Java, but that's not a feature of the language per se.
Python is a scripting language. It's almost fully dynamic, in that you can (if you want) rewrite class definitions during execution time based on user input. This is, on my philosophical level, an architectural feature of an interpreted language, and any compiled version of Python is going to have to include a compiler and/or interpreter to deal with these quibbles at run-time.
My point, in short, is that these architectural features aimed at the interpreted environment are a source of potential errors, and that they don't compile well; therefore Python is not a good candidate for use in compiled code. Python is was specifically designed for running in an interpreter. Why would you want to use it anywhere else?
Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
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 and great. Horrid experiences were with the few projects I've been where there was no concept of automated testing.
I mean, shit, good programmers have been implementing their own automated tests in one way or another even before the term "unit test" was introduced in the agile lingo. And normal companies that do not have their heads up their buttholes have plans that take into account some form of testing.
Deadlines always exist, and many times things have to be shipped out without full tests. This is typically the norm for, say, delivering an emergency patch.
But these are the exceptions rather than the norm. And in all cases, you simply put the missing tests on a backlog and re-calibrate your plans for the next sprints to take these into account.
If you are working in a company where code quality always suffer due to dealines, then get a different job somewhere else.
And if *you* happen to be the cause of such mishaps, please get out of the industry. It takes one crappy programmer to deliver poorly tested, badly written code that ends up requiring an army of engineers to deal with it.
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.
One of the great things about Python is that usually someone has already solved your problem, and their solution is superior to whatever you might have tried first.
In [1]: import numpy as np
In [2]: %time rolls = np.random.randint(1, 7, size=(2, 1E6))
CPU times: user 27.1 ms, sys: 4.63 ms, total: 31.7 ms
Wall time: 31.3 ms
Numpy is a Python numerics package implemented in C.
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.
Some privacy policy Slashdot.
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.
Some privacy policy Slashdot.