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.
...can be found here.
I prefer Ruby, but there seem to be a lot of healthy discussions of various language features and ideas across the scripting language community. The "Python comparison page", for example, has a link to John Ousterhout's paper on why scripting languages are useful - even thought he wrote the paper about Tcl, it's just as applicable to Python or Ruby.
The Army reading list
"Python has been an important part of Google since the beginning, and remains so as the system grows and evolves. Today dozens of Google engineers use Python, and we're looking for more people with skills in this language." said Peter Norvig, director of search quality at Google, Inc.
Open source, expressive (very short code can achieve a lot), readable (very short expressive code is easily groked -- fewer bugs), no direct pointer manipulation (safe -- fewer bugs), integrates nicely with other languages, runs on a variety of platforms, very easy to learn.
I, too would recommend learning python. It is a very good, language. Zeolotry is another thing though. Keep your mind open. Learn all the languages you can. This book, I can't comment, although I received it a week ago I haven't gotten around to reading it yet.
I have the fist edition of this book. It has help me considerably, but it seemed as though I always had to use google to supplement it with code/examples. I guess I wanted to see more real world work in the book rather than what seemed to me to be generic theory explained via simplistic samples.
Maybe its just me though.
The / in
While TCL remains my personal favorite, Python is really good, except for the creating-your-own-extensions part. The Python's C API needs a lot of catching up to do to match the excellence of TCL's.
In Soviet Washington the swamp drains you.
This is not a religious argument; I'm not advocating that python is the one language you should use or anything like that. In fact, not having an "ideology" is one of python's major strengths.
If you're asking "why python", ESR has said it better than I ever could.
I'm yet another of those who experienced extremely small turnaround times for python programs. It took me a week, working part time (I estimate about 30 hours) totally, to release 1.0 of gretools, starting from scratch. I had not written a single line of python code before that, mind you.
Why python is great:
Its not a religion. It doesn't force its style of thinking on you. Functional programming, excellent string manipulation tools, classes, inheritance, exceptions, polymorphism, operating system integration, they're all available. This is python's biggest advantage. Whichever background you're coming from, you can very quickly become effective at python.
Incredibly compact code. This is largely a consequence of the previous point. Apart from that it is dynamically typed, and has lots of other cool features. Like doing away with braces for delimiting blocks. People who know nothing about the language flame it for using indentation, but I have never found it confusing, and it makes the code smaller far more readable.
A user-friendly programming language! You aren't going to believe this until you've actually programmed in python. Its got this amazing property that if you can express a thought in constant space mentally, then you can code it in a constant number of lines, most of the time in a single line. In other words, the abstractions of the programming language match the "natural" abstractions of programmers very closely. After just a couple of days I got so used to this that I began to "predict" language features intuitively. At one point I just knew there had to be a language construct for something I was trying to do, and found that it was the reduce function.
Simple syntax. Python manages to have all these features while retaining a very simple syntax, perhaps even simpler than C. This is a big plus, because it gets out of the way and Does What You Mean.
Convinced? Get started now!
Except that Python uses dynamic typing, not static typing. Variables are untyped but hold references to typed objects.
> There is nothing, and I do mean NOTHING that
> a real Unix professional can do with Python
> or Perl that he or she can't do with awk, sed,
> and grep.
Awk? Sed? Bah! There's nothing you can do in awk and sed that you can't do with plain, simple assembly language opcodes!
The Army reading list
Python doesn't have static typing; it has dynamic typing like Lisp, Ruby, Perl, etc. The difference between Python and Perl is that Perl has rather weak dynamic typing. For example, Perl tries to treat strings and numbers as the same type (resulting in the use of strange constructs such as the value "0 but true"). Python and most other dynamically typed languages have stronger typing, with distinctions between strings, integers, floats, etc.
Static typing means that each variable is only allowed to hold values of one type. Usually the variable types are manually declared (as in C or Java), but some languages (like Haskell, IIRC) can infer the types.
I don't think *all* the O'Reilly books are good but the Python books (I own several) are really excellent: they are written by people that have been involved with the language for a long time and that really *think* in Python and like the language. Glad to see Python is still doing well.
there's no place like ~
This sums it up really:s id=3882
http://www.linuxjournal.com/article.php?
I like Python because of the line numbers and the goto statement. Why don't they add those features to Visual Basic?
If tits were wings it'd be flying around.
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).
One more time, for the majority of people who don't understand:
Strong typing is when your language will only allow appropriate operations to be performed on values of the appropriate type.
Weak typing is the opposite, where a language will implicitly convert between (possibly incompatible) types or will simply allow any operation to occur.
Static typing is when a language enforces its typesystem (whether it be strong or weak) at compile time.
Dynamic typing is the opposite, when a language enforces its typesystem at runtime.
Python is strongly, dynamically typed. If you try to perform an integer operation on a string, it will check this at runtime and raise an exception. It will not perform the operation.
Perl is weakly, dynamically typed. If you try to perform an integer operation on a string, it will implicitly convert that string to an integer (using 0 in the case of strings that aren't a valid representation of an integer). It does this at runtime.
Haskell is strongly, statically typed. If the compiler cannot prove that all your operations are performed on values of the appropriate type, it will not compile your program.
C is weakly, statically typed. It will implicitly convert beteween incompatible values (pointers and ints, for instance) but it will determine which implicit conversions will occur at compile time (as well as reject some other conversions or type errors).
Python is not in any way statically typed. Perhaps only moderators who actually know Python should get mod points on articles such as these (yes, I know that'd be impossible, but it'd ridiculous that the parent post got modded up to 5, interesting when it's blatantly and obviously wrong).
Jeremy
Looking for a Python IRC bot?
I'm not sure which Python you're referring to, but it doesn't sound like the www.python.org one!
Python's intellectual ancestor was the language ABC, not Perl or TCL. Python's object system is very clean and well thought out, not accreted into the language. New style classes are an elaboration of that, merging the concept of a type and a class.
I'm not sure which "aspects from Camel" fuck up the whole situation. You're one example about continuations and GC "occultism" doesn't really help. 99% of the wonderful Python applications out there have no need of such stuff, and if you did, maybe Stackless Python (a variant) might interest you.
Python has all the necessary features to build very robust and maintainable systems. It's library is excellent, and it's C API is extremely clean for both embedding and extending.
A valid criticism for *some* applications is that it's slower than C or C++. This should come as no surprise since Python is interpreted and highly dynamic. Fortunately, Python can easily be extended such that critical sections can be coded in C, although most applications won't need to bother. It's also an excellent prototyping language so that if you *did* want to rewrite it in a static language like C++, you'd have an excellent basis for it.
Well, from the perspective of a long-time Perl developer, Python has a certain elegance in it's language design (apart from using whitespace as syntax ;) that some other languages lack (in fact, it reminds me of Smalltalk in many ways, for this very reason). It has taken many of the features from various object oriented, functional languages, and scripting languages, and tied it up in a nice, clean, consistent little package.
OTOH, Perl as a language is unbelievably flexible and convenient to work with, but it's most definitely a more "hackish" language, in that it's grown more than it's been designed. As such, it's definitely more of a developer's language (ie, has many of the features which, while not necessarily incredibly elegant, are *really* convenient) than a theorist's language.
So, then, why pick one over the other? Frankly, in the end, I suspect it's just personal preference (or predjudice).
Isn't that reason _enough_? Some people may not know what they want, but just about everyone knows when they DON'T like something. Perl makes me itch.
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
Actually, if anyone is interested in learning Python and doesn't mind reading a book on their computer, there's a bunch of free ebooks available on the Python Documentation page (as well as a comprehensive list of books that are only printed). I've read a few of them, most of them are pretty good, in particular "How to think like a Computer Scientist" is a very good text for a less experienced programmer and Bruce Eckel's "Thinking in Python" is a nicely comprehensive coverage of Python (not unlike his "Thinking in Java" and "Thinking in C++" books).
Even if you do mind reading books on your computer screen, most of these books (actually I think all of them) are also available as physical printed books as well.
Thinking In Python by Bruce Eckel
An Introduction to Python by Guido van Rossum, and Fred L. Drake, Jr. (Editor)
How To Think Like a Computer Scientist: Learning with Python by Allen Downey, Jeff Elkner and Chris Meyers
Dive Into Python: Python for Experienced Programmers by Mark Pilgrim
Text Processing In Python by David Mertz
Python Language Reference Manual by Guido van Rossum
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?...
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.
A mention of the Psyco Python runtime compiler is in order. It's simple to use as well - all you do is put this at the top of your entry script:All routines called are then compiled from bytecode on-the-fly into native x86 code. It's not quite as fast as C - but with Psyco you can easily get close, especially if you design your algorithms properly.
While I'm here, these are the Python packages that I find essential once I have the base installation (which includes the IDLE IDE). I've used these packages under Windows, but most work on Linux as well:
You need a book to learn Python?!??!!? My god, I'm an old C++ programmer, Python is like a gift from a god!
You just have to bang your head against the keyboard a couple of times and I bet you it compiles!
Aide-toi, le Ciel t'aidera - Jeanne D'Arc.
It's too easy to accidentally use do-while when you should have just used while. It actually makes the language less error-prone, because in those few cases where you do have an unconditional first pass, you are forced to structure the code differently and actually think about what you're doing.
You can always transform: do stmt while foo into stmt while foo stmt which isn't even longer (if stmt is actually many statements, it should be a function anyway). It's not worth introducing an abusable language construct just so you get to be lazy and not code a function when you should.
Boost.Python
I sort of hope that Parrot will help Perl overcome its introversion, and let it integrate more readily with other languages.
I think that C++ and Python form a dynamic duo. You can put the effort into compiling items that benefit from such, and glue them together in Python most agreeably.
The C++ standard library focused on Platonic abstractions, but Boost is pulling C++ in more mainstream directions. And that's a beautiful thing.
While issuing random plugs, check out Leo. It's not too often you see a fresh interface on an editor.
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
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-
Total agreement.
I've used python for several years, but only 2 weeks after stumbling across "Programming Ruby" (Available free at http://www.rubycentral.com/book/), I've switched all new development to Ruby. As a language, it just clicks for me. It's like the best of all possible worlds. It brings in the cleanliness of Python (without the whitespace issues, for those who dislike that), the hack value of Perl (tightly integated regex, etc), the OO of smalltalk/java (for those that like that kind of thing), and essentially anonymous functions like a functional language. Many things are expressed in a very logical manner, and this allows you to concentrate on how to accomplice a task.
A comparison:
Python
adict = {'key':'val','key2':'val2','key3':3.14}
for k in adict.keys():
----print 'k -> '+str(adict[k])
Ruby
adict = {'key'=>'val','key2'=>'val2','key3'=>3.14}
adict.each{|k,v| puts k,' -> ',v}
TODO: Something witty here...
Anyway. I immediately ran off to the nearest bookstore and grabbed the first edition of the book. I read it once through and it--along with a lot of googling--helped me understand what I was doing, but once I had gone through it once I couldn't use it to recall the details of what I had been taught. If I wanted to look up something that I knew I had learned *from the book* I would have to look it up *on the web* (e.g. syntax or the required parameters of a function) because the index was useless. I never found anything I needed from that book once I did the initial once-through reading.
Though let's not gloss over the fact that I obviously learned python fairly well from this book because I did get the job! So sure, if you need to learn the language, the first edition did the job, but you'd better buy a *real* python book while you're there at the bookstore because as soon as you were done with Learning... it was nothing more than a paperweight.
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
actually an enormous game has been written in "stackless" python: EVE online. the reviews of EVE have been mediocre, but most have complimented the game's graphics. it's also an enormous world with all kinds of complex rules. according to the developers, it wouldn't have been possible without python.
i think EVE proves that python is ready for big projects, even when performance is critical.
Programming can be fun again. Film at 11.
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).
Continuations are also incredibly useful for massively scalable network applications. They are arguably the best way to write them, in terms of code readability and performance.
Here's a program I've written in ruby, just today, in about 2 hours.
It generates a graphical waveform from the component harmonics, as well as graphing the first 10 harmonics.
Source Code: http://tylere.com/waveform.rb.txt
Some Examples:
Square Wave
A Phased Sine Wave
Triangular Wave
Sawtooth Wave
TODO: Something witty here...
sorry eclectum, you can't use print in a list comprehension. SyntaxError.
The comprehension doesn't add anything to this example. Let's stick with the time-honored:
for k, v in adict.items():
print k+'->'+v
(you can put it on one line if you really want)
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.
:)
.append() loops in most cases. I also love generators and find they are amazing ways to write extremely simple code that yields generic iterators. (Extremely useful for the implementation of __iter*__ methods).
Lets call this the foo indirection.
The foo indirection is useful because it releases the tight coupling between the foo(obj) call, and the obj.__bar__() call.
For example, the int(object) call is implemented by usually calling object.__int__(), but this is not necessarily so.
int is a type whose constructor converts objects to an integer using __int__ or other protocols/methods.
For example, int(some_string, 16) will convert the string to an integer treating it as an ascii representation of a hexadecimal number. The string does not necessarily have __int__ and/or does not necessarily support the same arguments as int.
The foo indirection also allows for later modifications of things like the len() function without modifying the __len__ method protocol.
The foo indirection is exactly the same as the indirection you get when using object[subscript], where that subscript may be an index or a slice. It used to call __getitem__ or __getslice__, which is a messy protocol. Because of this indirection, the messy protocol was now cleaned to __getitem__ which may take an integer index or a slice object index, while still supporting __getslice__.
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.
Python does not try to be Smalltalk, however it is indeed very similar to Lisp in many ways. However, there is a fundumental difference in the philosophies of Lisp and Python. Lisp tries to be the "language of languages", where macros let you variate the language to your specific needs. Python tries to be the "uniform language", where macros would never get in the language because they harm uniformity.
Unfortunately Python stole the thunder and now python has the great docs and 3rd-party libraries, while Ruby lingers and grows slowly.
Fortunatly, if you ask me
And Python has the arrogant, Perl-like community now, that thinks jamming list comprehensions and generators into everything makes you "cool".
I simply find comprehensions more readable than
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").
The number of lines is often a good (perhaps rough) indicator of the number of bugs in the code. Code that's not written does not have bugs. I find the "advanced" generator-using solutions very elegant and general.
Python does not claim there is "one way to do it". Python claims "there should be one obvious way to do it, preferrably only one". There can be more than one obvious way, and there always is more than one way (just not obvious).
I found it very unhelpful, and again was confused when people said it was such a great book.
Most of my development deals with internationalisation and support for many languages and scripts. For that reason, I prefer Python, because one can make all internal strings Unicode no longer have to worry about a million character sets. Ruby, on the other hand, lacks support for Unicode. I know the iniciator of Ruby comes from Japan, where because of CJK chauvinism Unicode sadly hasn't caught on yet, but this is the 21st century, and a scripting language without support for Unicode is just unacceptable.
I agree, ODBC is a critical feature for a "glue" language like Python. There's mxODBC, but commercial use costs $75 per end-user or $1,250 per developer. Most of Python's other database modules are free, but ODBC is needed to fill a lot of gaps.
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."
By the way, Lisp vs Python comparison by the famous AI hacker Peter Norvig is way better as it's more objective (less biassed) and it has very important details and very clear examples.
Less is more !
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.