Beginning Python: From Novice to Professional 436
nazarijo writes "Python seems to be devouring everything these days,
with more and more people using it for serious projects. It's quickly
supplanting Perl in some circles, and with good reason. It's a powerful,
richly featured language with boatloads of extensions. And, unlike Perl,
it's very easy to do complicated things in simple, legible code. Python
books are still only a small part of the shelf at your local bookstore
when you compare it to the popularity of Perl, but which ones are the gems
and which ones are fluff? Having looked at a lot of Python books in the past
couple of years, I think that Beginning Python: From Novice to Professional
is the one that I'll most recommend to people." Read on for the rest of Jose's review.
Beginning Python: From Novice to Professional | |
author | Magnus Lie Hetland |
pages | 604 |
publisher | Apress |
rating | 8/10 |
reviewer | Jose Nazario |
ISBN | 159059519X |
summary | Tour the Python language, from basics to advanced modules |
Beginning Python is loosely grouped into three main sections. The first deals with Python fundamentals, all the goodies that are inherent to the language and the modules that it ships with. It's surprising to see how rich the language is out of the box, especially when compared to some other scripting languages. The second section would be the chapters covering popular extensions for a variety of services. These include network and web programming, SQL objects, and even GUI programming. And finally the third section is a set of 10 projects in Python, which bring everything together in a concise fashion.
I like this book a lot because it is very clear in its delivery, both the prose and the code examples used, and is consistently Pythonic. The Python language lends itself to a powerful programming style and, unlike Perl, many Python developers I know don't bother with a dozen ways to perform a simple action, they get it done and move on. What you wind up with is clear code that's easily understood by someone new to the language.
Unlike what the title would suggest, Beginning Python isn't only for the first few weeks with the language. The book is large and in depth, and the coverage of material is fantastic in many ways. You get a quick tour of the basics and then you move on to an overview of the language and then its common features. The inclusion of the 10 projects is another benefit to the intermediate user. She can refer back to this book for additional information and pointers from time to time, it wont sit still on her shelf.
That said, there are a few things in the book that I tend to disagree with. For example, the author dissuades you from using destructors in your code, but in my experience they're far more reliable, and a better place to do some cleanup, than he states. A few chapters are also a bit skimpy when they didn't need to be. For example, Chapter 18, which covers packagers like the distutils component from Python, needed to be fleshed out a lot more. This is a powerful feature in Python and sound docs on it should just be there. There's no reason to hold back on something so vital. The section on profiling in Chapter 16 is also a bit thin around the middle when it needn't be. While this seems like a minor point, having a reference to speeding up code (and measuring the improvements) is always nice. And finally, Chapter 17, which covers extending Python, is simply too short for its own good. A more in depth example would have been appreciated.
I have begun recommending this book to people I know that are smart and program in other languages, but aren't very familiar with Python. Many beginners books only take a person so far before they become a useless item on the shelf. This means that he $30 or more that was spent is now gone, so I've grown to be observant of how long I expect a book to be useful. I anticipate the useful shelf life of Beginning Python will be longer than average for most general purpose programming books for a single language. What's more is that it's not a dry reference book. Couple this to a Python cookbook for recipes and you have a two volume "mastering Python" series.
If you've been curious to learn Python and haven't yet found the book that speaks to you clearly, this may be the one. I'm pleased with the quality of the writing, the examples, and the quick pace of the book. While it's nearly 30 chapters in length, most of them are short and focused, making them easily digestible and highly useful. Overall probably the best Python books I've had the good fortune of reading."
You can purchase Beginning Python: From Novice to Professional from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
O, yeah? (Score:3, Insightful)
Perhaps it is time for you to get a perl book or take CS-101 course or something.
Re:Totally fresh in programming (Score:3, Insightful)
Ha!
Insightful.
Yes, yes, true.
I skilled up when young, by typing in programs from the back of Family Computing.
I don't know what to tell "kids these days."
Entering computer programs, by hand, worked well for me.
Re:Devouring? (Score:4, Insightful)
Those are unfilled jobs. Jobs that they couldn't find someone for without resorting to advertising. In other words, the jobs that get listed on job sites are the ones that no one wants.
Has to bash on Perl (Score:2, Insightful)
This must mean you aren't able to write legible Perl code. Perl has been making complicated things simple for more than a decade. If you don't know how to write clean code, then your Python will also suck.
Re:Devouring? (Score:1, Insightful)
about dynamic grouth.
Do the same query one more time in a month and then
compare numbers. Ones that change faster are the ones
that deserve "devouring" attribyte.
Pretty sure, Python will be one of them
Re:Totally fresh in programming (Score:3, Insightful)
The kicker: If you understand the principles behind it, you can easily learn any language.
You probably want to skip alot of the theory behind data structures and whatnot at the beginning though.
Simple, Legible Code (Score:5, Insightful)
And, unlike Perl, it's very easy to do complicated things in simple, legible code
The issue with Perl isn't that it's particularly hard to do complicated things with simple, legible code (not more so than a lot of other languages, anyway), but that it's very, very easy to do something extremely quickly, which often - but not always - means code that makes sense at the time but isn't necessarily readable, or leads to overly terse code. Yes, Perl makes it easy to do things wrong (and a lot of people out there do use Perl to make unreadable programs), but that doesn't mean that it can't be used to do things correctly as well as any other language.
python regexes (Score:2, Insightful)
Re:Totally fresh in programming (Score:4, Insightful)
Out of curiosity, what other language qualifies as platform independent by your definition? Answer: there isn't one. In the context of what we currently have, today, in 2006, Python is just about as platform independent as anything else.
Re:Has to bash on Perl (Score:5, Insightful)
And, unlike Perl, it's very easy to do complicated things in simple, legible code.
This must mean you aren't able to write legible Perl code. Perl has been making complicated things simple for more than a decade. If you don't know how to write clean code, then your Python will also suck.
Not directed at the parent, but at the Perl-snipping in the original post....
<RANT>I'm a professional python programmer, and I've been making my living at it for a number of years now. (It was my embracing of python that allowed me to transition to a 100% MS free workspace.) I started using it a project a few years ago, and it's just stuck for a number of reasons. (meta-classes, extensibility, etc.)
One thing that drives me buggy about some python evangelists, (and many evangelists, in general) is the need to bash anything that is not their favorite brand (be it Creative vs iPOD, Python vs (insert any language here). And so on. The fact of the matter is that Perl is a perfectly good language. I don't use it on a regular basis personally, but I've seen, read and understood a good deal of Perl code w/o a hassle. (yes, I've seen some scary code, but I've seen scary code in C++, Python, Java, etc., etc., etc.)
Sometimes we just have to admit that there are multiple good tools that we could use, but we have a personal (and possibly irrational) preference for one over the other. That's life as a human being (which I'm assuming at least 99% of the readers out there are. :) ). Just because some people use Perl, doesn't make my choice of python (of C++, my other "main" language) any less valid.
It's real life, not a multiple choice test -- there is no single "correct" answer.
</RANT>Ok, I'm done... back to work.
Re:Totally fresh in programming (Score:1, Insightful)
* You can replace PHP with any other language. Although I recommend PHP just because it's a fairly simple and widely used language.
Re:Totally fresh in programming (Score:3, Insightful)
I've used python as a language to teach people programming (in the context of a physics course, to do numerical simulations). It was OK, but the significance of whitespace was a major barrier for them to overcome. If I was doing it over again today, I'd probably use Lua, which has a very standard C-like syntax. Another consideration is that it might be good to use a language that's small enough to run in a web browser [hobix.com].
Python's strengths, AFAICT, are its pure object-oriented design and the large set of libraries available for it. IMO, neither of these are particularly important for teaching beginners to program.
python isn't just for web apps (Score:3, Insightful)
(It's also about twice as fast, but honestly if Ruby is too slow for your project a factor of 2 probably isn't going to save you. Still, speed is a nice bonus.)
most helpful book (Score:2, Insightful)
It'd be a book about programming and algorithms in general. Its MUCH easier to root around in a 'hello world' program or the like if you understand things like loops, if/then/else statments, function calls, etc. Even the fundamental idea of declaring and using a variable.
Re:O, yeah? (Score:5, Insightful)
Perhaps it is time for you to get a perl book or take CS-101 course or something.
I've got both. So, tell me: what's the syntax for returning multiple complex objects from a function in such a way that they don't have to be dereferenced by the calling code (that is, they can be used directly, just like you were returning a single scalar)?
Python example from the interactive shell:
I'm not overly stupid, but doing something so relatively easy in Perl put me at my limits. I like Perl, and I've written many large programs in it, but I always had to fight against the syntax. Python got out of the way and let me concentrate on logic instead.
-1 Troll for Submitter (Score:3, Insightful)
So can Perl.
Python is for architects - Perl is for lumberjacks (Score:2, Insightful)
When you build a house you need an architect and specific design rules so other people in the project can do their part. It takes a long time to build it, and someone has to live in the house a long time.
When you cut down a tree you're only interested in the fastest way possible to get it down safely. Who cares if it's pretty. If you didn't like the way the first one fell, you can make adjustments on the next.
A house builder wouldn't tell a woodcutter which axe to use. He doesn't care. Of course, woodcutters have no business building houses.
Personally? I like being a lumberjack. Nothing like fervorishly hacking away and yelling "TIMBER!" from a safe distance.
Re:My 2 scents (Score:2, Insightful)
Re:O, yeah? (Score:3, Insightful)
Perhaps it is time for you to get a perl book or take CS-101 course or something.
It is, I quite agree, entirely possible to write fairly simple clear legible code in perl. It does require a few extra hoops, but in general it isn't that hard, it just requires a fair bit of self-discipline or, if you're working in a team, some very rigid well defined coding standards
Jedidiah.
Re:O, yeah? (Score:3, Insightful)
Because the language designer probably doesn't know as much about your team and the problems you're trying to solve as you do.
Re:O, yeah? (Score:5, Insightful)
In perl you have to be explicit to dereference.
In python you have to be explicit to copy.
Your case happens to be one where references are needed, and in python, implicit. In cases where copying of arrays is need, python needs to be explicit; perl is implicit. So ignoring the ridiculous 'without dereferencing' restriction:
sub foo {
return { 'one' => 'ein', 'two' => 'zwei' }, sub { my $x = shift; return $x + 5; }, "string"
}
my ($a, $b, $c) = foo();
print $a->{'one'};
print $b->(5);
print $c;
Re:Totally fresh in programming (Score:3, Insightful)
Many of us - both beginners and not-so-beginners - like dynamic typing for the exact opposite reason: things that would be errors in statically typed languages are perfectly acceptable in dynamic language. Implicit, pervasive polymorphism can let you create some very robust code in a relatively short amount of time. Writing "foo_int", "foo_string", "foo_float", etc. gets a little old, even if it does give you some explicit guarantees about the data you're manipulating.
Re:Devouring? (Score:5, Insightful)
You are forgetting that this is the Slashdot Universe, where...
"Java/Intel/Oracle/Sun/Windows is dying..."
"No-one uses commercial UNIX..."
"Open Source is GPL and anything else is evil.."
"PHP scales for everything...."
and...
"Favourite open-source language [fill in the blank] is the future and everyone is already using it...."
When in this Slashdot dimension, you have to understand the rules!
Re:I tried python (Score:1, Insightful)
Re:Devouring? (Score:3, Insightful)
Re:Totally fresh in programming (Score:4, Insightful)
Only if you already have a variable called 'strikr'. Otherwise, you'll get a runtime exception. Not having to initialize variables is completely different from "all variables come pre-initialized to some value". If you type "a=b", b better be defined. It doesn't have to be *declared* (nor does a), but it must contain a meaningful value (which could be None - python has a concept of null).
vulnerable to pretty printers
Who would run some random code formatter on their code when it's not designed for their language? That's just idiocy. Even still, if it treats "4 spaces" in one place as the same as "4 spaces" in another, the code will still work - python just cares that you're *consistant* with your indentation. Meanwhile, with C/C++, you can shove the brackets almost anywhere and do the most bizarre indentation imaginable, and it's perfectly content with you - bad form.
Python is a straightjacket (Score:4, Insightful)
In Python, it is easy to make legible code, but it is difficult to make illegible code.
That's because Perl is versatile, flexible. Python forces you to do things The Python Way(tm). I've tried Python a couple of times, and I keep going back to Perl. Maybe I'm just a rebel, but I don't like a language telling *me* what to do (queue "In Soviet Russia..." joke here).
And, yes, I mostly just hate the whitespace-as-blocking braindamage. It's like Guido loved LISP, but hated the braces, so he re-invented LISP, poorly. But that's why I love programming-- everybody gets to choose their favorite poison.
Re:Damn perl bashing (Score:4, Insightful)
Oddly enough I'm reading a book on Applescript right now (not because I really want to but because I need to write some fairly complicated scripts in it.) The book reminds me of perl in it's early days when it says how easy it is to do something or how Applescript magically does something for you, like understand whether you're in a string or math context. This seems good to beginners. But it the long run I think if lends itself to muddled code. There's just a little too much congratulations to each language for it's cleverness (and perl definitely is clever).
As far as Python goes god knows I tried to read either Programming or Learning Python but I just gave up. It just didn't hold my interest at all. Give me Java, or legible Perl any day!
Re:Totally fresh in programming (Score:3, Insightful)
Basically, if you stick with the core modules and don't hardcode pathnames or do other bad things, then your programs will be portable. Venture past that, just as with any other language, and all bets are off.
Artical summary blows it again. (Score:4, Insightful)
I just burned through the flamewall on this issue not three days ago. I use Python instead of Perl, love Python best of all languages currently, and may even like the book reviewed. But it is superstitiously ignorant to declare any language makes it "easier" to program in. Can we just once have a discussion of the strengths and weaknesses and merits and demerits of any language at all, instead of talking about it like it was a laxative? "Makes the code soft and it flows out smoothly!" No, it doesn't: nothing does; hard programs are hard to write, easy programs are easy to write. I'll even save the time and copy my closing argument from last time:
I know a secret. It's a secret you only find out after programming for a while. It's one you obviously don't know if you ask me which programming language is the "easiest".
There is this public perception, unanimous in user-land, and even permeating to the very depths of Slashdot, which goes: "Computers are only hard because evil computer programmers deliberately set out to make them hard." And the secret is: that that's a falsehood. Computers are not made artificially difficult. It does no good to tell you this; this is a special kind of secret that you can only learn through experience.
The experience of struggling to design a usable user interface for your own system. The struggle to overcome the barriers of closed systems, lack of documentation, and misinformation everywhere you turn. The exasperation of dealing with users who come to you with the attitude that your program broke on purpose, you should fix it without knowing what the error was, and it's too hard to learn anyway because you make it difficult, because you're "evil".
Programming experience erases that mental line drawn between user and programmer. You get experience on both sides of the fence, and eventually you see that there is no such thing as artificial complication. Interfacing with a machine upon which we have taught electricity to think and where we hope to make it sing and dance for us is inherently complicated TO START WITH, and the various tools we use to perform our tasks - why, each and every one was written by average people like you and me who also sat down with a clean file and furrowed their brow and wondered "How can I do this? How can I make it so people will use it?"
No, you still have that mental mindset that there are programmers who deliberatly design things to be difficult, that it's all in spite, that they're laughing at you. Who, except as a joke, would deliberately make a programming language "hard to learn"? To fail at your task and blame your tool is simply a form of denial so that you don't have to face the fact that you have given up on trying to use something (no matter if it's COBOL or Javascript or Perl or freaking TECO, even!) that hundreds of other people have used successfully.
There is no "easy". There is no "hard". There is only "Task".
Now, you want to talk about an "easy" language? Binary, of course! Binary has just two commands (one and zero) so it's the fastest to learn, has cross-platform compatibility built-in (all computers know binary!), is easiest to test (no compiler or interpretter required, just "Rite 'n' Run"!), is readily available everwhere (ALL programs are "open source" in binary!), and needs no extension libraries (Binary can do it all!). If you thought this paragraph was stupid, this is how stupid the rest of you sound to me when you hyperfocus on "easy" and act like there's no other aspect to programming.