New to Python: my impression v. Perl/Ruby

[John J. Lee]

Just want to state explicitly from the outset that this is all
intended as friendly argument.  Personally, I take it as a compliment
when somebody takes me seriously enough to argue with me ;-)

Wayne Folta <wfolta at netmail.to> writes:

> 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.

Great.

I don't think that makes any difference to what I said, though: the
correctness or otherwise of your statements is not dependent on which
language you happen to like best.


> 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!

Absolutely not!  I see nothing even faintly wrong with arguing in
favour of Ruby in comp.lang.python.  Go ahead!  In return, I'll tell
you off if I think what you say is wrong or poorly reasoned :-)


> > 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)"?)

I see your point, though I think there's an significant difference in
degree here.  Still, perhaps it's useful (while timeouts aren't
directly supported by clients of the socket module) to point people to
the socket module docs for the default timeout setting.  Try writing a
doc patch and submitting it to SF.

[...]
> > ...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,

Sorry, I was following the sloppy practise of using the word "bug" to
cover all sins.  By "bug" here I mean "gross missing feature" --
something that really should be there, but nobody has got round to
implementing yet.  I didn't mean that socket or its client modules
behave incorrectly according to their docs (apart from raising
socket.timeout, of course!).


> but I sure hope that the exception is handled and then
> re-raised as timeout_proto or something distinct from error_proto. I

ATM, client modules know nothing about socket timeouts, AFAIK, so
socket.timeout is never caught.  Not sure whether it's best to just
let socket.timeout propagate, or wrap it in an error_proto (if the
latter, a subclass certainly sounds like a good idea).

[...]
>  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.

set_timeout() methods (or similar) need to be added to these modules.

[...about "Real OO"...]
> 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 know what "pure OO" is either!


> > 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

In saying "...I'm not sure that Python's docs should be in the
business of educating people about that..." I wasn't trying to imply
that you're uneducated!  I assumed you simply failed to make the
"obvious" (or not) connection from timeouts to the socket module, and
made the point that the documentation cannot and should not attempt to
solve all such problems.


> and a supposed bug on Python's part. Once you've done that, yes,
> it is no longer illuminative.

My point was simply that there are no .set_timeout() methods in the
client modules of socket because nobody has yet got round to it, not
because of some deliberate design decision...


> 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.

...oh, I see.  Yes, that's a substantive difference in design, I agree
(and perhaps in culture -- I wouldn't know, not having used Ruby).

(Mind you, it's far from obvious that it's good OO design to have
every class that uses sockets inherit from a socket class, let alone
that it's a requirement for "pure OO" (which remains undefined).  Does
"pure OO" mean simply "using inheritance a lot"?  Hmm, I didn't mean
to get into this debate: I just wanted to point out the lack of
meaning in saying "Real OO" without defining what you mean.)


> 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.
[...]

I'm not competent enough to make judgements on these issues, I think:
they're quite subtle.  I certainly agree that such decisions about
language and library design should be made on the basis of pragmatic
design informed by a good understanding of underlying principles, not
on some blinkered notion of "purity", but I've not much idea where
Ruby fits on that scale, so I'll shut up :-)


John