New to Python: my impression v. Perl/Ruby

[Wayne Folta]

John,

I think one problem here is that somehow I left a paragraph out of my 
original posting. After years and years of Perl use, I evaluated Ruby 
and Python and have adopted Python. Ruby intrigues me, but it's not 
what I will use to get things done. I thought that as a newcomer to 
both, I though I might have a different perspective from people who 
were native users, hence my posting.

I can see that without that info, it may have appeared that I was 
possibly advocating Ruby over Python, which would be inappropriate in a 
Pyton forum. I apologize for the confusion!

> Well, that's not exactly a huge leap given any knowledge of how the
> internet works.  I'm not sure that Python's docs should be in the
> business of educating people about that...

There's no necessary connection between the protocol stack and software 
packages. It's good and sensible that POP3 is built on socket, but it 
could be based on my_sockets or _socket or who knows what. I'm not 
asking that the entire protocol stack be documented, and it's not as if 
"obvious" things aren't documented in detail elsewhere in Python. (For 
example, there's an entire paragraph on socket's gethostname(). I could 
rhetorically say this is so obvious it should be replace with "returns 
host name" or "see GETHOSTNAME(3)"?)

For me, it's just totally natural that I'd say, "The POP3 package is 
built using the socket package and socket exceptions are not caught by 
POP3." That single sentence immediately tells me everything I needed to 
know. That's the way I'd document any higher-level package, regardless 
of whether there was an obvious candidate for underlying packages (or 
classes) or not. For me, it's as basic as mentioning what types a 
function returns, or what types its arguments are, or what class is a 
subclass of another.

> ...but the fact that there is no timeout support in client modules of
> the socket module is a known bug:

This is a bug? I guess it can cause problems in the underlying package, 
but I sure hope that the exception is handled and then re-raised as 
timeout_proto or something distinct from error_proto. I personally 
prefer fine-grained exception, which I believe best takes advantage of 
multiple-except try clauses. I hate catching something then having to 
sort through variables to figure out what really happened.

 From an external viewpoint I don't see that much difference between 
"fixing" this bug and simply documenting the other exceptions you might 
see from underlying packages.

> In the absence of some explanation of what you mean by "Real OO", that
> sounds trollish.

No trolling intended. I simply have read what Python advocates say 
about Python and what Ruby advocates say about Ruby (in comparison to 
languages like Python) and said that. I'm making no statement about 
reality, but simply about what advocates mantras are. (Or actually, as 
I carefully said, "might be".)

(Actually, now that I reread it, I should've said "pure OO", which I 
believe is more reflective of their statements. And this has some basis 
in fact, I believe, if you look at the v1 of Ruby and Python and what 
is first-class and what is not.)

> I don't see how a missing feature in Python reveals any difference in
> culture between Python and Ruby, other than perhaps that the Ruby
> people like implementation inheritance more than the people who
> designed the Python standard library.

You have taken my observation and transformed it into ignorance on my 
part and a supposed bug on Python's part. Once you've done that, yes, 
it is no longer illuminative.

Again, as you yourself say, they chose to subclass protocol services 
off of a class 'protocol' and Python did not. In fact, Python chose to 
not subclass POP3 from anything. Why? Because of the culture, in my 
opinion. Ruby emphasizes OO and that it's "pure OO" (their opinion) and 
so an implementation that involves a Smalltalk-ish subclassing of 
everything recommends itself.

Python has a different culture where such strict tree-like class 
structure does not recommend itself. Python's "batteries included" 
philosophy resulted in a more straightforward and (mostly) better 
documented way to do it.

Intellectually, I prefer Ruby. Ruby and Smalltalk intrigue me. But the 
"pure OO" approach (my words this time) is annoying, and even at some 
point inconsistent, as I mentioned in my paragraph about 0.step(). I 
feel like Python has got the right balance where it's OO and pretty 
much fully so, but not fanatically so. And it's what I've adopted.

You can see that the three languages have been driven by central 
personalities and the user groups reflect these personalities. Before 
Perl were various languages and shell/awk/sed. Larry triangulated 
things and stuck a flag in the semi-script, expedient measure area. 
("Do what I mean", "Swiss Army Chainsaw".) His brilliance was in tying 
very disparate tools together in one syntax that hung together and did 
the "right thing" based on how these other tools worked.

(And he got away from some of the weaknesses of shell scripts, such as 
substititional evaluation, which were there because they were 
interactive first, then became scripting languages. Somehow TCL didn't 
learn this kind of lesson and I've never liked it.)

Unfortunately, expedient measures don't scale well and Perl has, as 
someone famous said, pushed well beyond its performance envelope. 
(Probably in v5.)

Guido was able to learn from Perl and moved more towards a language 
that was farther removed from "scripting" with a cleaner syntax, solid 
OO, etc. But he kept what I'd consider the best of Perl's expediency 
philosophy. ("Batteries Included".)

Matz saw both of these and went for a "pure", Smalltalk-ish OO. He also 
kept some of Perl's expediency, but in more of a syntactic way. So I 
find Ruby to be a strange combination of almost fanatical OO philosophy 
but at the same time an expediency of syntax.

Just my opinion. But in summary, I prefer Python. It feels right to me. 
OO but not what I'd call the fanatical OO of Ruby. Clean syntax. Good 
packages bundled. Somehow, I would say it has a less-flexible syntax, 
but more-flexible philosophy. (Which is good.)

(OK, one thing to add is I'm on MacOS X and Python's EasyDialogs is 
VERY convenient and attractive and the other programs don't seem to 
have an equivalent. It just doesn't make sense for me to program with 
something that doesn't allow for easy GUI interaction with a user on a 
machine with such a great GUI.)