New to Python: my impression v. Perl/Ruby

[Wayne Folta]

I've been a long-time Perl programmer, though I've not used a boatload
of packages nor much of the tacky OO.

A couple of years ago, I decided to look into Python and Ruby. Python
looked OK, but not that different. I did like the indent-as-group idea,
which was different. Ruby looked very cool. But it was impossible to
get good documentation. It seemed like a Japanese cult with a few
western initiates.

Well, MacOS X ships with Perl, Python, and Ruby (and PHP, and ...) so I
recently figured I'd try them again. I still find Ruby more intriguing,
but I've settled on Python. Why?

Well, Perl is an expedient measure that (for me) doesn't scale up and
has that horrible OO syntax. (So I never used it much.) If you're going
to read someone else's Perl, you had better be "in the zone".

A couple of months ago, I'd written a quick Perl script that would
"unstick" a co-worker's POP email. The problem is the Windows-based POP
server is too stupid to realize a message does not end in CRLF, so it
just appends a period then CRLF thinking it's doing well. But the
period ends up not being alone on a line, so it's not a valid
termination to the message. So their email program hangs waiting for a
proper termination. Sigh.

A week ago, the script broke because I hadn't properly accounted for
the fact that the user might have hundreds of messages queued up. (I
hadn't used a Perl POP package, which might've handled it, but just
threw it together myself. Yes, that would've made the Perl code more
competitive with the other two solutions.)

So I decided this might be a nice exercise to try Python. And it went
together very quickly using Python's POP3 package. Then I decided to
try it in Ruby. I think one little portion of the code shows the
difference between the two cultures.

The problem is that the message is not properly terminated, so you need
to time out and catch that timeout to realize, "hmmm, malformed". In
Python I had:

M = poplib.POP3 ('172.16.30.1') ;
M.user ('foo') ;
M.pass_ ('bar')

num_mesgs = len (M.list ()[1])
bad_mesgs = 0

for msg in range (num_mesgs):
try:
M.retr (msg + 1)
.... blah blah...

How do I get it to time out after 5 seconds and how do I catch that?
The online docs are pretty good, but I had to guess that POP3 was built
on the socket package. Looking at socket's docs I found the proper
command and exception. I had to include:

socket.setdefaulttimeout (5.0)

before the POP3 commands to set the default socket timeout to 5
seconds. And

except socket.timeout:

is the proper way to catch the timeout. Both of these things are in the
socket documentation.

Contrast this with Ruby. The Ruby docs are less complete, but they did
mention that POP was subclassed from protocol and you'd have to look at
protocol's source to see how it works. Looking through protocol, I
figured out what to do and it was more elegant.

The protocol class had a read_timeout, but since Ruby's mantra might be
said to be "Real OO", the POP code had been written such that you could
say

pop.read_timeout = 5

after the POP open and it set the timeout for that pop connection to 5
seconds. Almost as if POP passed the read_timeout upstream to socket
automatically. (I don't think Ruby does, but it's coded to look that
way.)

My experience is limited, but it feels like this example gives a good
feel for the two languages. Python was better documented and things
came together quickly. Ruby ultimately had a more elegant solution, but
was more poorly documented. This echoes the mantras: Python's is
"Batteries Included", while Ruby's might be "Real OO".

On a personal note, I usually prefer an elegant solution, but when the
language goes so far as to consider

0.step(360, 45)

to be reasonable, my head hurts. I know there's syntactic sugar so I
don't have to code like that. I know everything's an object. But,
dammit, a constant integer is an integer with constant value and
causing it to iterate is a step too far.

[John J. Lee]

Wayne Folta <wf****@netmail.to> writes:
[...]

So I decided this might be a nice exercise to try Python. And it went
together very quickly using Python's POP3 package. Then I decided to
try it in Ruby. I think one little portion of the code shows the
difference between the two cultures.

The problem is that the message is not properly terminated, so you
need to time out and catch that timeout to realize, "hmmm, malformed".
In Python I had:

M = poplib.POP3 ('172.16.30.1') ;
M.user ('foo') ;
M.pass_ ('bar')

num_mesgs = len (M.list ()[1])
bad_mesgs = 0

for msg in range (num_mesgs):
try:
M.retr (msg + 1)
... blah blah...

How do I get it to time out after 5 seconds and how do I catch that?
The online docs are pretty good, but I had to guess that POP3 was
built on the socket package. Looking at socket's docs I found the
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...

proper command and exception. I had to include:

socket.setdefaulttimeout (5.0)

before the POP3 commands to set the default socket timeout to 5
seconds. And

except socket.timeout:

is the proper way to catch the timeout. Both of these things are in
the socket documentation.
....but the fact that there is no timeout support in client modules of
the socket module is a known bug:

http://www.python.org/peps/pep-0042.html
http://www.python.org/sf/723287

It's likely to be fixed in 2.4. Timeouts on sockets were only
introduced in Python 2.3 (though there was a third party library
around for a long time before that that retrofitted timeouts into
the standard library).

Contrast this with Ruby. The Ruby docs are less complete, but they did
mention that POP was subclassed from protocol and you'd have to look
at protocol's source to see how it works. Looking through protocol, I
figured out what to do and it was more elegant.
Well, if Python's standard library had decided to subclass everything
from some 'protocol' base class, the docs would indeed mention that
fact, since that's would be a fact about the Python standard library
rather than about networking in general. It didn't, so it doesn't.

The protocol class had a read_timeout, but since Ruby's mantra might
be said to be "Real OO", the POP code had been written such that you

[...]

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

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

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

[Terry Reedy]

"Wayne Folta" <wf****@netmail.to> wrote in message
news:ma**************************************@pyth on.org...

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.
If you consider it a doc bug or deficiency, go to sourceforge, register if
you have not, go to
http://sourceforge.net/tracker/?grou...70&atid=105470
and file a doc bug. Give a specific suggestion like the above, giving the
LibRef section number and paragraph and sentence number where you would put
it. Also give rationale (which I snipped) explaining how as newcomer you
were unnecessarily puzzled, mislead, or whatever. If one of doc
maintainers agree, as they have with most of my suggestions, they will add
to the LaTex master copy. (Patches to LaTex source are also accepted, for
those who can make such.) This is how docs keep getting better.
No trolling intended.

I never thought so. You have obviously looked pretty carefully at all
three languages, given them a fair if personal evaluation -- and come to
the 'right' conclusion ;-).

Terry J. Reedy

[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 <wf****@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

[Francis Avila]

Wayne Folta wrote in message ...

John,
[snippage](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.)
[snippage]
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.

[snippage]

Some time ago I wrestled with the Ruby-Python claim-counterclaim to "purity"
in
http://groups.google.com/groups?hl=e...readm=vug18vkm
jpiice%40corp.supernews.com&rnum=1&prev=/groups%3Fq%3D%2522Francis%2BAvila%2
522%2Bruby%26hl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26selm%3Dvug18vkmjpii
ce%2540corp.supernews.com%26rnum%3D1

(Whew)

Anyway, as yet I fail to see how one can be considered more "pure" than the
other. Ruby prefers subclassing, but this seems cultural rather than
technical. Further, Python can be said to be more "pure", in the naive
sense that everything that's first class is an object, and more entities are
first class in Python (e.g. methods). I don't think this is a *good*
argument, but it's not a ludicrous one, because it at the very least
illustrates that we don't know what the heck "pure" means in this context.

To me, the argument that there is a direct correspondence between "OO
purity" and "similarity to SmallTalk" begs the question, because it
presupposes that SmallTalk is pure OO. But there's nothing about SmallTalk,
aside from the historical accident of being one of the first languages to
use objects pervasively, which suggests to me that its is the "purest" way
of doing OO. Rather, OO is too general a concept to admit of a single
paradigm which is imitated to greater or lesser degrees in one or another
language. The difference between Ruby and Python already illustrates that
OO does not admit of a single paradigm, because of the attribute/message
distinction. Which is more pure? It's like asking whether meat as food is
more pure than vegetables.

Of course, this is just my current thinking on the subject. If someone
presents an argument that Ruby is more pure which I find compelling (Leaving
aside the old CPython wart of unsubclassable base types.), I'll certainly
repent my assessment. But I'll still prefer Python, because using 'impure
OO' doesn't bother me one bit. ;)

--
Francis Avila

[Phil Tomson]

In article <ma**************************************@python.o rg>,
Wayne Folta <wf****@netmail.to> wrote:

-=-=-=-=-=-

I've been a long-time Perl programmer, though I've not used a boatload
of packages nor much of the tacky OO.

A couple of years ago, I decided to look into Python and Ruby. Python
looked OK, but not that different. I did like the indent-as-group idea,
which was different. Ruby looked very cool.
It _is_ very cool.
But it was impossible to
get good documentation.
It' s not _impossible_. Check out www.ruby-doc.org, for example.
It seemed like a Japanese cult with a few
western initiates.
You should see us at the Ruby conferences. We must speak only in haiku
until we reach the Master level ;-)

Well, MacOS X ships with Perl, Python, and Ruby (and PHP, and ...) so I
recently figured I'd try them again. I still find Ruby more intriguing,
but I've settled on Python. Why?

Don't lose the intrigue. ;-)
Well, Perl is an expedient measure that (for me) doesn't scale up and
has that horrible OO syntax. (So I never used it much.) If you're going
to read someone else's Perl, you had better be "in the zone".

A couple of months ago, I'd written a quick Perl script that would
"unstick" a co-worker's POP email. The problem is the Windows-based POP
server is too stupid to realize a message does not end in CRLF, so it
just appends a period then CRLF thinking it's doing well. But the
period ends up not being alone on a line, so it's not a valid
termination to the message. So their email program hangs waiting for a
proper termination. Sigh.

A week ago, the script broke because I hadn't properly accounted for
the fact that the user might have hundreds of messages queued up. (I
hadn't used a Perl POP package, which might've handled it, but just
threw it together myself. Yes, that would've made the Perl code more
competitive with the other two solutions.)

So I decided this might be a nice exercise to try Python. And it went
together very quickly using Python's POP3 package. Then I decided to
try it in Ruby. I think one little portion of the code shows the
difference between the two cultures.

The problem is that the message is not properly terminated, so you need
to time out and catch that timeout to realize, "hmmm, malformed". In
Python I had:

M = poplib.POP3 ('172.16.30.1') ;
M.user ('foo') ;
M.pass_ ('bar')

num_mesgs = len (M.list ()[1])
bad_mesgs = 0

for msg in range (num_mesgs):
try:
M.retr (msg + 1)
... blah blah...

How do I get it to time out after 5 seconds and how do I catch that?
The online docs are pretty good, but I had to guess that POP3 was built
on the socket package. Looking at socket's docs I found the proper
command and exception. I had to include:

socket.setdefaulttimeout (5.0)

before the POP3 commands to set the default socket timeout to 5
seconds. And

except socket.timeout:

is the proper way to catch the timeout. Both of these things are in the
socket documentation.

Contrast this with Ruby. The Ruby docs are less complete, but they did
mention that POP was subclassed from protocol and you'd have to look at
protocol's source to see how it works. Looking through protocol, I
figured out what to do and it was more elegant.

Um hmmm...

A quick google for: Net::Protocol Ruby revealed several hits.
Although, I'll admit, I didn't find the Net::Protocol class covered in the
Pickaxe book.
The protocol class had a read_timeout, but since Ruby's mantra might be
said to be "Real OO", the POP code had been written such that you could
say

pop.read_timeout = 5
So what's the problem?

after the POP open and it set the timeout for that pop connection to 5
seconds. Almost as if POP passed the read_timeout upstream to socket
automatically. (I don't think Ruby does, but it's coded to look that
way.)
Did it or didn't it? You never really say what happened with the Ruby
code.

My experience is limited, but it feels like this example gives a good
feel for the two languages. Python was better documented and things
came together quickly. Ruby ultimately had a more elegant solution, but
was more poorly documented. This echoes the mantras: Python's is
"Batteries Included", while Ruby's might be "Real OO".
Ok, so you basically had to read the code and then you got it working, or
no?

On a personal note, I usually prefer an elegant solution, but when the
language goes so far as to consider

0.step(360, 45)

to be reasonable, my head hurts. I know there's syntactic sugar so I
don't have to code like that. I know everything's an object. But,
dammit, a constant integer is an integer with constant value and
causing it to iterate is a step too far.

Different strokes for different folks, I guess. I remember that one of
the first things I saw about Ruby was that even interger literals were
objects that can receive messages and thinking how wonderful that was.
As you say, you're not forced to do things this way - you can use 'for'
for example, but:

10.times do something end

is somehow so clear. It's almost zenlike.

;-)

Phil

[Eddie Corns]

Wayne Folta <wf****@netmail.to> writes:

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.

Python: because everything's not an object

?

[Terry Carroll]

On Mon, 19 Jan 2004 23:09:06 -0500, "Francis Avila"
<fr***********@yahoo.com> wrote:

Some time ago I wrestled with the Ruby-Python claim-counterclaim to "purity"
in
http://groups.google.com/groups?hl=e...readm=vug18vkm
jpiice%40corp.supernews.com&rnum=1&prev=/groups%3Fq%3D%2522Francis%2BAvila%2
522%2Bruby%26hl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26selm%3Dvug18vkmjpii
ce%2540corp.supernews.com%26rnum%3D1

(Whew)

http://tinyurl.com/2exx8

[Ville Vainio]

>>>>> "eddie" == Eddie Corns <ed***@holyrood.ed.ac.uk> writes:

eddie> Python: because everything's not an object

Umm... everything is an object in Python (except "names"). Whether
everything has to be shoehorned into classes is another thing.

--
Ville Vainio http://tinyurl.com/2prnb

[Ville Vainio]

>>>>> "Phil" == Phil Tomson <pt***@aracnet.com> writes:

Phil> Different strokes for different folks, I guess. I remember
Phil> that one of the first things I saw about Ruby was that even
Phil> interger literals were objects that can receive messages and
Phil> thinking how wonderful that was. As you say, you're not

Ints are objects in python too:

a=1
a.__lshift__(1)

2

Though "sending messages" to int literals is a syntax error.

Phil> 10.times do something end

Phil> is somehow so clear. It's almost zenlike.

It's cute and fun to write, but less cute for people who have to read
lots of such code in short time. I have a soft spot for such style
also; I kinda like Python's "\n".join(["foo","bar"]), even if most
seem to consider it a wart for readability reasons.

--
Ville Vainio http://tinyurl.com/2prnb

[Serge Orlov]

"Ville Vainio" <vi**************************@thisisspamprotection tut.finland> wrote in message
news:du*************@mozart.cc.tut.fi...

>> "Phil" == Phil Tomson <pt***@aracnet.com> writes:
Phil> Different strokes for different folks, I guess. I remember
Phil> that one of the first things I saw about Ruby was that even
Phil> interger literals were objects that can receive messages and
Phil> thinking how wonderful that was. As you say, you're not

Ints are objects in python too:
a=1
a.__lshift__(1) 2

Though "sending messages" to int literals is a syntax error.

Try this:

(1).__lshift__(1)

2

-- Serge.

[John Roth]

"Ville Vainio"
<vi**************************@thisisspamprotection tut.finland> wrote in
message news:du*************@mozart.cc.tut.fi...

>> "Phil" == Phil Tomson <pt***@aracnet.com> writes:
Phil> Different strokes for different folks, I guess. I remember
Phil> that one of the first things I saw about Ruby was that even
Phil> interger literals were objects that can receive messages and
Phil> thinking how wonderful that was. As you say, you're not

Ints are objects in python too:
a=1
a.__lshift__(1)

2

Though "sending messages" to int literals is a syntax error.

Phil> 10.times do something end

Phil> is somehow so clear. It's almost zenlike.

It's cute and fun to write, but less cute for people who have to read
lots of such code in short time. I have a soft spot for such style
also; I kinda like Python's "\n".join(["foo","bar"]), even if most
seem to consider it a wart for readability reasons.

Tacking an iterator on an integer isn't all that bad from
a readability viewpoint - ***except*** for the .step iterator.
..times, .upto and .downto read very nicely, but .step is
a monstrosity. Conceptually, .step has three parameters,
and separating them that way simply doesn't read right.

It's also not consistent with the .each iterator attached to
range objects in Ruby, which is at least intelligible, and is
consistent with the way iterators are done with all other
objects.

The trouble with <string>.join(<sequence of strings>) in Python
is that it reads backwards, at least to me. The arguement that
..join isn't a natural list method makes sense, but nobody seems
to want to consider that there are other solutions that read
fairly well. Of course, they're also consequences of fairly
generic changes to the language.

John Roth


--
Ville Vainio http://tinyurl.com/2prnb

[Francis Hwang]

Ville Vainio <vi**************************@thisisspamprotection tut.finland> wrote in message news:<du*************@mozart.cc.tut.fi>...

Phil> 10.times do something end

Phil> is somehow so clear. It's almost zenlike.

It's cute and fun to write, but less cute for people who have to read
lots of such code in short time. I have a soft spot for such style
also; I kinda like Python's "\n".join(["foo","bar"]), even if most
seem to consider it a wart for readability reasons.

A lot of this has to do with how you conceptualize objects. In some
languages objects are big and heavyweight. So the few things that get
to be called Objects are blessed with special powers, and the lowly
primitive values are supposed to look up to them with admiration and
reverence.

In other languages everything can be an object, which means that you
have to think of the "object" idea differently. In Ruby integers are
objects, but there's a lot of syntactic sugar to make that happen.
After all,

10.times do something end

is basically just fancy talk for

for (i = 0; i < 10; i++ ) { something }

or whatever you think should be more explicit. This method might break
your conceptual model of what an object is, depending on which model
you like.

Personally, I love the Fixnum#times method, since it means I never
make fence-post errors anymore. More time for interesting problems,
less time spent on tediously stepping through code one iteration at a
time. And if my conceptual model is getting in the way of my ability
to write error-free code, then it's the conceptual model that has to
change.

Besides, once a language is Turing-complete, everything else is
syntactic sugar. So you might as well get the best syntactic sugar you
can get ...

Francis