New to Python: my impression v. Perl/Ruby

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • Wayne Folta

    New to Python: my impression v. Perl/Ruby

    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.setdefau lttimeout (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_timeou t = 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

    #2
    Re: New to Python: my impression v. Perl/Ruby

    Wayne Folta <wfolta@netmail .to> writes:
    [...][color=blue]
    > 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[/color]

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

    [color=blue]
    > proper command and exception. I had to include:
    >
    > socket.setdefau lttimeout (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.[/color]

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

    This PEP contains a list of feature requests that may be considered for future versions of Python. Large feature requests should not be included here, but should be described in separate PEPs; however a large feature request that doesn’t have its own P...



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

    [color=blue]
    > 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.[/color]

    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.

    [color=blue]
    > 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[/color]
    [...]

    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

    Comment

    • Wayne Folta

      #3
      Re: New to Python: my impression v. Perl/Ruby

      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!
      [color=blue]
      > 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...[/color]

      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.
      [color=blue]
      > ...but the fact that there is no timeout support in client modules of
      > the socket module is a known bug:[/color]

      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.
      [color=blue]
      > In the absence of some explanation of what you mean by "Real OO", that
      > sounds trollish.[/color]

      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.)
      [color=blue]
      > 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.[/color]

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


      Comment

      • Terry Reedy

        #4
        Re: New to Python: my impression v. Perl/Ruby


        "Wayne Folta" <wfolta@netmail .to> wrote in message
        news:mailman.52 4.1074550958.12 720.python-list@python.org ...[color=blue]
        > 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.[/color]

        If you consider it a doc bug or deficiency, go to sourceforge, register if
        you have not, go to
        Download Python for free. The Python programming language, an object-oriented scripting and rapid application development language. You can download it from http://www.python.org/download

        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.
        [color=blue]
        > No trolling intended.[/color]

        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


        Comment

        • John J. Lee

          #5
          Re: New to Python: my impression v. Perl/Ruby

          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@netmail .to> writes:
          [color=blue]
          > 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.[/color]

          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.

          [color=blue]
          > 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![/color]

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

          [color=blue][color=green]
          > > 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...[/color]
          >
          > 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)" ?)[/color]

          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.

          [...][color=blue][color=green]
          > > ...but the fact that there is no timeout support in client modules of
          > > the socket module is a known bug:[/color]
          >
          > This is a bug? I guess it can cause problems in the underlying
          > package,[/color]

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

          [color=blue]
          > but I sure hope that the exception is handled and then
          > re-raised as timeout_proto or something distinct from error_proto. I[/color]

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

          [...][color=blue]
          > 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.[/color]

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

          [...about "Real OO"...][color=blue]
          > 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.)[/color]

          I don't know what "pure OO" is either!

          [color=blue][color=green]
          > > 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.[/color]
          >
          > You have taken my observation and transformed it into ignorance on my
          > part[/color]

          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.

          [color=blue]
          > and a supposed bug on Python's part. Once you've done that, yes,
          > it is no longer illuminative.[/color]

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

          [color=blue]
          > 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.[/color]

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

          [color=blue]
          > 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.[/color]
          [...]

          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

          Comment

          • Francis Avila

            #6
            Re: New to Python: my impression v. Perl/Ruby


            Wayne Folta wrote in message ...[color=blue]
            >John,
            >[/color]
            [snippage][color=blue]
            >(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.)[/color]

            [snippage]
            [color=blue]
            >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.[/color]

            [snippage]

            Some time ago I wrestled with the Ruby-Python claim-counterclaim to "purity"
            in

            jpiice%40corp.s upernews.com&rn um=1&prev=/groups%3Fq%3D%2 522Francis%2BAv ila%2
            522%2Bruby%26hl %3Den%26lr%3D%2 6ie%3DUTF-8%26oe%3DUTF-8%26selm%3Dvug1 8vkmjpii
            ce%2540corp.sup ernews.com%26rn um%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

            Comment

            • Phil Tomson

              #7
              Re: New to Python: my impression v. Perl/Ruby

              In article <mailman.493.10 74484056.12720. python-list@python.org >,
              Wayne Folta <wfolta@netmail .to> wrote:[color=blue]
              >-=-=-=-=-=-
              >
              >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.[/color]

              It _is_ very cool.
              [color=blue]
              >But it was impossible to
              >get good documentation.[/color]

              It' s not _impossible_. Check out www.ruby-doc.org, for example.
              [color=blue]
              >It seemed like a Japanese cult with a few
              >western initiates.[/color]

              You should see us at the Ruby conferences. We must speak only in haiku
              until we reach the Master level ;-)
              [color=blue]
              >
              >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?
              >[/color]

              Don't lose the intrigue. ;-)
              [color=blue]
              >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.setdefa ulttimeout (5.0)[/color]

              [color=blue]
              >
              >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.
              >[/color]

              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.
              [color=blue]
              >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_timeo ut = 5[/color]

              So what's the problem?
              [color=blue]
              >
              >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
              >automaticall y. (I don't think Ruby does, but it's coded to look that
              >way.)[/color]

              Did it or didn't it? You never really say what happened with the Ruby
              code.
              [color=blue]
              >
              >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".[/color]

              Ok, so you basically had to read the code and then you got it working, or
              no?
              [color=blue]
              >
              >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.[/color]

              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

              Comment

              • Eddie Corns

                #8
                Re: New to Python: my impression v. Perl/Ruby

                Wayne Folta <wfolta@netmail .to> writes:
                [color=blue]
                >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.[/color]

                Python: because everything's not an object

                ?


                Comment

                • Terry Carroll

                  #9
                  Re: New to Python: my impression v. Perl/Ruby

                  On Mon, 19 Jan 2004 23:09:06 -0500, "Francis Avila"
                  <francisgavila@ yahoo.com> wrote:
                  [color=blue]
                  >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&r num=1&prev=/groups%3Fq%3D%2 522Francis%2BAv ila%2
                  >522%2Bruby%26h l%3Den%26lr%3D% 26ie%3DUTF-8%26oe%3DUTF-8%26selm%3Dvug1 8vkmjpii
                  >ce%2540corp.su pernews.com%26r num%3D1
                  >
                  >(Whew)[/color]




                  Comment

                  • Ville Vainio

                    #10
                    Re: New to Python: my impression v. Perl/Ruby

                    >>>>> "eddie" == Eddie Corns <eddie@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

                    Comment

                    • Ville Vainio

                      #11
                      Re: New to Python: my impression v. Perl/Ruby

                      >>>>> "Phil" == Phil Tomson <ptkwt@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:
                      [color=blue][color=green][color=darkred]
                      >>> a=1
                      >>> a.__lshift__(1)[/color][/color][/color]
                      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

                      Comment

                      • Serge Orlov

                        #12
                        Re: New to Python: my impression v. Perl/Ruby


                        "Ville Vainio" <ville.spamster meister.vainio@ thisisspamprote ctiontut.finlan d> wrote in message
                        news:du71xpue3r m.fsf@mozart.cc .tut.fi...[color=blue][color=green][color=darkred]
                        > >>>>> "Phil" == Phil Tomson <ptkwt@aracnet. com> writes:[/color][/color]
                        >
                        > 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:
                        >[color=green][color=darkred]
                        > >>> a=1
                        > >>> a.__lshift__(1)[/color][/color]
                        > 2
                        >
                        > Though "sending messages" to int literals is a syntax error.[/color]

                        Try this:[color=blue][color=green][color=darkred]
                        >>> (1).__lshift__( 1)[/color][/color][/color]
                        2

                        -- Serge.


                        Comment

                        • John Roth

                          #13
                          Re: New to Python: my impression v. Perl/Ruby


                          "Ville Vainio"
                          <ville.spamster meister.vainio@ thisisspamprote ctiontut.finlan d> wrote in
                          message news:du71xpue3r m.fsf@mozart.cc .tut.fi...[color=blue][color=green][color=darkred]
                          > >>>>> "Phil" == Phil Tomson <ptkwt@aracnet. com> writes:[/color][/color]
                          >
                          > 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:
                          >[color=green][color=darkred]
                          > >>> a=1
                          > >>> a.__lshift__(1)[/color][/color]
                          > 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.[/color]

                          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

                          [color=blue]
                          >
                          > --
                          > Ville Vainio http://tinyurl.com/2prnb[/color]


                          Comment

                          • Francis Hwang

                            #14
                            Re: New to Python: my impression v. Perl/Ruby

                            Ville Vainio <ville.spamster meister.vainio@ thisisspamprote ctiontut.finlan d> wrote in message news:<du71xpue3 rm.fsf@mozart.c c.tut.fi>...
                            [color=blue]
                            > 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.[/color]

                            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

                            Comment

                            Working...