Slashdot Mirror
Learning Python, 2nd Edition
Python is a dynamic, interpreted, object oriented language used for both scripting and systems programming. Python is known for being easy to learn and use, while also being powerful enough to be used for such projects as Zope and the Chandler project. Its growing popularity is also based on its reputation for fostering programmer productivity and program maintainability. One drawback sometime cited is its relatively slow execution speed compared to compiled languages such as C.
For myself, I have probably read too many books about Python, but that is because I am an amateur hacker who learns programming slowly, and I find that reading several books about the same topic, covering the subject matter from different angles, allows me to better absorb the material. For me, this was a good review of the core language and a welcome refresher course on the newer aspects introduced in versions 2.2 and 2.3. For anyone who is new to Python and wants to learn from the ground up, this book would be a great place to start.
Mark Lutz is an authority on Python and one if its leading teachers, with both Learning and O'Reilly's Programming Python to his credit, as well as the courses and seminars he teaches professionally. In updating the original version, which was already very good, Mark has polished the chapters on the core language to a nearly perfect level, while his co-author David Ascher has done the same on the more advanced aspects of the book. In addition, Mr Lutz has benefited from extensive feedback from students and readers, and his explanations therefore anticipate common misunderstandings. Each chapter is accompanied by a problem and exercise section and answers are included at the back of the book.
A major addition to the new edition is a chapter on "Advanced Function Topics," including list comprehensions, generators and iterators. Python is sometimes used with a functional programing style almost similar to Lisp, although to List purists that may sound like heresy. The recent versions of the language have significantly upgraded Python's support for the functional style. Functions cover three chapters in the 2nd edition instead of just one.
Another major change since the first edition is extended coverage of Modules, which now occupies four chapter instead of just one. Python modules are a high level package structure for code and data, and they help facilitate code reuse. Yet another addition is coverage of Python's "new style classes." Coverage of classes and object oriented programming has been greatly expanded and now includes five whole chapters and almost 100 pages. Coverage of exceptions now is expanded to three chapters.
If you have been considering learning Python, now would be a great time since this new book is the perfect introductory text. If you already know Python and have read the first edition of Learning Python or another introductory text, then this book may not be essential since the new language features are covered pretty well on the web in various places, and you might be better advised to read one of the other fine books on non-introductory aspects of Python. But this book is about as good an introduction to the language as you are likely to find. The book does not cover all of the Python libraries nor many other topics, but it does briefly touch on the major libraries, frameworks, gui toolkits, and community resources.
If you want to learn the core Python language quickly, this may be your best bet. Learning Python only covers the basics, but it is deep in information on what it does cover. Well written, understandable, and in a very logical arrangement, this book is densely packed with info.
I have often found myself returning to the original book, and the new book will now fill this role. It is deep in information, well written, and a joy to read. For an experienced programmer who is just learning Python, it may be possible to thoroughly learn everything about the core language in one reading of this book. For relative newbies, it will be an often-used resource.
To read more reviews of books about Python, visit the Python Learning Foundation. You can purchase the Learning Python, 2nd Ed. from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
I would recommend "Python In A Nutshell" as it cuts to the chase and doesn't teach you programming so much as giving you what you need to know in Python. If you can already program, the "Nutshell" book is pretty good, plus the author can always be found around the Python Newsgroup(s).
You mean they've fixed it so you don't have to rigidly adhere to Python's indentation conventions? 'Cause that and tab damage are the things that keep me from learning it.
Python is basically an attempt to merge Perl, TCL/TK and object orientated programming.
No way in hell. Python tries its best to avoid perlisms, and TCL/Tk doesn't even come close. Python has a strongly typed object system with one namespace.
I don't think that we really have to discuss the problems of Perl's "object system"
Perls object system is a hack. Python object system fits like a glove. ISTR that Larry kinda "copied" the objsystem from Python (and not vice versa), but it didn't really fit perl.
or the shortcomings of TCL/TK.
Shortcomings of TCL/Tk have really nothing to do with the topic. Don't try to sneak TCL/Tk into this. This has got to be the clumsiest strawman argument I've seen in a while. Chewbacca lives on Endor?
The result can be seen when you try to program a caller frame instance-preserving continuation in Python.
What do you mean? Closures (or "nested scopes" as they are referred to in the language docs - look them up before whining) work as expected. Can you give an example of the thing you are talking about in a language you know (assuming you know one). Are talking about what Stackless Python is trying to do?
But when the project advances they suddenly notice that python doesn't provide all necessary features and a whole rewrite is in order.
You don't really need "features", you can use libraries to add "features" and the core language is flexible enough for pretty much any tasks.
Save your wrists today - switch to Dvorak
Yeah, it's really sad how many large projects fail because they're implemented in a language that doesn't properly support continuations....
Wait a minute, I've been in the computer industry for decades, and other than myself, I could probably count on one hand the number of people I've met who even know what a continuation is. Other than as an amusing tool to utterly confuse any but the most advanced developers, continuations are probably only useful for coroutines, and coroutines are mostly useful for iterator generators, which recent versions of Python have generators nicely packaged in an easy-to-understand syntax (the yield statement).
Since few if any other popular languages give you even this much, it must be truly amazing that any software works at all.
One drawback sometime cited is its relatively slow execution speed compared to compiled languages such as C. this is the tradeoff between interpretation languages (python) and compiled languages (c, java). you get flexiablity in your code but you lose some speed in runtime. Well, most people use python to write scripts that are smaller than what they would write in C++ or java. you are not going to write half life 2 in python, right?...
I prefer Ruby as well, but I can already see that it's not going to be a language I can spend lots of time learning right now. Although I like programming languages, I don't have enough free time to spend time learning a language that won't be immediately useful. For the record, when I need a scripting language, I use Perl unless the design needs to be object oriented, at which point I drop back into Ruby.
I seem to have a different view of what a scripting language should be than most of the people who write them. I write scripts when a sudden need for a small program comes along. I need the script to not take a long time to write, even though I might not be ``current'' with the language. To me, the most useful scripting language would be one with strict syntax and a large mass of well documented libraries to dip into. No scripting language I've seen so far has strict syntax. ``There's more than one way to do it'' seems like it'd hurt you if you weren't well versed in the language and were trying to write a script that only needs to run once. It also seems like dynamic typing would hurt the effort as well. Eliminating as many points of unsureness as possible would be a boon. Java's syntax would make a terrific scripting language.
Anyway, that's just my opinion. I don't mention large-ish software projects because I don't have lots of experience in them.
One of the things I initially judge a language by is how elegant it is to code the quicksort algorithm (yes, I'm aware Python has a built-in sort function -- that is not the point). Here's quicksort in Python:
def quicksort(list):
if len(list) > 1:
pivot = list[0]
left = [x for x in list if x < pivot]
right = [x for x in list if x > pivot]
pivot = [x for x in list if x == pivot]
return quicksort(left) + pivot + quicksort(right)
return list
I'd say this speaks for itself. Enjoy.
Heh. Sure, I _could_ write something with awk and sed to modify XML files a developer sends me. The question is, would anyone but me be able to understand the script well enough to modify it? Heck, could I, if I didn't have to do anything with it for a year?
Naked.
I'm a long time perl programmer. Recently I did some research into Python. It really does look to be a more elegant language and enforce some structure that is needed in Perl.
That said I can't justify the switch. There are just too many good modules available in Perl (esp for the engineering work I do). When python has the bredth of packages that Perl does, and when they have a nicely organized way to access said modules, I'll be happy to switch.
One should not theorize before one has data. -Sherlock Holmes-
It gives a thorough description of how to use Python; which is indeed easy to learn if you already know another language. But when the authors say that not having to compile Python programs means that development time is speeded up, perhaps they are overstating. For most programmers who use compiled languages like C or C++, the biggest time is taken up in finding a method that solves a problem, coding it and subsequent debugging. These days, compilers on recent hardware are fast enough that link/compile times are simply not a bottleneck to development productivity. So it is a bit of a straw dummy that the authors put forth.
However, they are absolutely spot on when comparing this to Perl or Tcl. Perl is powerful, but its code looks like assembler. Perl gurus tend to shrug when you point this out, usually saying they understand it, with the not-so-implicit suggestion that if you can't, it is your fault. But this leads to a real maintenance problem and a barrier to entry to others. The cleaner Python syntax can show coding intent far clearer. Plus, and more importantly, the object oriented nature of Python lets you scale up to much larger programs. This has always been a problem with scripting languages, all the way back to the various unix shell scripts and DOS bat files. Often, the most those ever gave you in terms of modular capabilities was the equivalent of subroutines. Which is strictly procedural and not OO.
By the way, there is a small contradiction between the above claim that Python is more understandable than Perl and the claim that it has an advantage over C++ or Java because it is not as verbose as those. Typically, in increasing amount of source code, you have Perl -> Python -> (C++,Java). If you think that Python is more understandable than Perl, then by that same logic, we could conclude that C++ or Java is more understandable than Python.
So if you are using Perl or Tcl and want something better, Python is a good choice. A good upgrade path.
But if you are currently using C or C++, with maybe X for graphics, or Java, then I suggest you stay with those. All three languages, with their graphics, give you a far richer toolset. Python would be a retrograde choice.
Excellent example:
1) I prefer the Python example. It's easier to read. And easier to write the first time. That's the reason Python is better than Ruby: when you write code, you get it right the first time more often. And that's such a huge advantage.
Of course, you screwed up. (I assume you wanted to print the value of k rather than the letter k)
2) You used a comprehension in Ruby but not in Python. And adict.items() would have been easier than adict.keys()
To be more fair:
adict = {'key':'val','key2':'val2','key3':3.14}
[sys.stdout.write(k+'-> '+str(v)+'\n') for k,v in adict.items()]
But if I was writing the code, I'd use a for loop rather than a comprehension.
But for penis length competitions, we'll use the latter.
Bryan
Programming can be fun again. Film at 11.
Same here..
.. that's fine, but Python is half-baked. I'm confused why people say it is so great and elegant. Is it just because it's NotPerl(tm)? (I actually like the whitespace parsing in Python, btw).
I tried Python at first and found it much nicer than Perl. Like many others I was hungry for a non-compiled, object-oriented language which was for large projects, not just quick hacks. Someday, computers will be fast enough so that all our coding is done in these languages.
But immediately the "object model" if you want to call it that got on my nerves. Why "len(list)" and not "list.len()"? Why "'\n'.join(array)" instead of "array.join('\n')"? What's with the simplistic scoping? Why all the underscores? Why "self" everywhere, and why is it so unpythonic to just call it "s" instead? Do I really have to type parantheses all the time? Where are the first-class regexps? Does it make sense that for many built-ins, "foo(obj)" calls "obj.__bar__", why not just use "obj._foo()" directly and eliminate "foo()" from the language.
Lots of other people found it much nicer than Perl, and jumped on the bandwagon
I guess I'm one of those weenies that believes all languages eventually become Lisp or Smalltalk, and any sharp corners that vary from those models will eventually be "filed off". I tried Ruby and discovered it was much more like Smalltalk. Very elegant and easy to write code. And coming from Perl, it has much of the power of Perl but in an object-oriented way. Unfortunately Python stole the thunder and now python has the great docs and 3rd-party libraries, while Ruby lingers and grows slowly.
And Python has the arrogant, Perl-like community now, that thinks jamming list comprehensions and generators into everything makes you "cool". Why do they think it's so cool to reduce the number of lines in a program? I own the "Python cookbook" and find it highly irritating. Rather than solving problems in a single elegant and general way, it presents each author's particular 'leet Python skills, and usually 4-5 different solutions (in a language that claims "one way to do it"). I found it very unhelpful, and again was confused when people said it was such a great book.
Python is moving in the right direction though. My fear is that someday it will be possible to write very elegant code in Python, yet still have to support all the Python 1.5 code out there, so the language will be a huge mess. Some may argue that it is already becoming a mess. I think Guido should come out with Python 3 and make it totally non-backwards compatible.
I'm probably forgetting quite a few things, but probably the most important difference for me is that I remember Python very easily, because it's simpler (compare java IO to python IO for a particularly egregious example), whereas if I don't use Java for a while, then I have to consult reference material a lot. I don't think I'm particularly abnormal in this respect, as I know plenty of other people who've observed similarly.
I prefer Python to Ruby, but your complaints about Python are right on, IMO.
Your "Python stole the thunder" analysis is not quite right, though, and it relates to why I prefer Python.
Ruby is as old as Python, but Matz wrote Ruby to do his own Japanese *nix work. He focused on his own needs, but made it available to all, so essentially he was focusing on the Japanese *nix community and their needs. The Japanese *nix community, for example, cares far more about handling legacy Japanese data than about handling new, multilingual Unicode data, so Matz's design decisions reflect this local bias, to the detriment of those of us with reverse priorities.
Japanese *nixers are a pretty small, insular community, but that's where Ruby has always been centered. These days, the circle has grown out from that center large enough that there's more for Westerners or non-*nix users to use, but the center is still on Japanese *nix users.
It's that focus that explains a lot of the weaknesses of Ruby as seen from the perspective of a Westerner who cares about cross-platform dev, internationalisation, good and plentiful English docs, a big English-speaking community of experienced users, etc.
I think Matz is a smart, humble guy with real talent when it comes to language design. I like him, and I like Ruby's design more than Python's in many ways, but his focus on Japanese *nix programmers and their local priorities has been a ball and chain around Ruby's ankle that I think explains the more rapid growth of Python worldwide (and Ruby's faster growth in Japan).
"Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."
I too prefer Ruby. And as such, it's nice to see Ruby being mentioned more often. Sure the Ruby community is smaller (in the US anyway) than the Python community, but we do seem to be steadily gaining new users (even some Python refugees).
The whole Ruby vs. Python issue is probably mostly a "different strokes for different folks thing". Either is a good choice to learn at this point. Try them both and see which one fits you better. In my case it mostly came down to the indentation- as-syntax issue with Python (often this is referred to as 'whitespace as syntax', but pretty much every language relies on whitespace somewhere, so indentation is more specific). I really strongly disliked Python's indentation-as-syntax 'feature'. I know that many Pythonistas will claim that with the right editor settings it's not problem, but for me not being able to cut&paste code is a deal-breaker (and having important pieces of your code be 'invisible' just doesn't sit well with me). I tried Python for a few days before trying Ruby and was bit a few times by the indentation-as-syntax thing - no thanks (but to each his own).
The culture of the two language communities also seems very different. Ruby's seems more 'free' (for lack of a better word), while Python's is, uh, more, um... well, I'm not wanting to start a flamewar here, but the Python folks do seem a tad bit more, uh, anal.. err, I mean 'uptight' (for lack of a better word).
By 'free' as applied to the Ruby community I mean that while there are some aspects of the language that some might consider 'dangerous' (the fact that classes are always open, for example) and others consider very powerful (I like the fact that classes are always open - it's a powerful feature) the attitude is that you're a grownup and you can figure out how to use these powerful features wisely, we're not going to constrain the language just because some kid might 'hurt himself'.
All this to say that I think that each language appeals to a different sort of person. Python probably tends to appeal to the safety conscious, neat person (and we need people like that, don't get me wrong). While Ruby probably tends to appeal to the more creative "don't cramp my style" type of person. That's not to say that Ruby is 'dangerous' - I'm starting to use it on a commercial project and it's a big productivity booster - just that you probably have to exercise a bit more wisdom when using it.