ReSpect RSpec »
« The Basics of REST in Rails

Contrasting Python and Ruby

Admittedly I’ve been caught in the community currents moving towards Ruby and Rails development triggered by the Pragmatic Programmers. While on the ride I’ve been weary of their seemingly direct competitors, Python and Django.
The choice of which to use has usually been an emotion charged debate.

While others have poked around and performing comparisons, I thought I’d take a quick look for myself.
There are two comparisons at play here which I’ll split into two entries: Python vs. Ruby, Django vs. Rails.

Here’s my take on Python vs. Ruby. Granted it’s a long way off comprehensive, biased by my knowledge of Ruby.

Ruby

Pro’s

  • Everything is an object
  • Method discovery built into the language
  • Language reads more naturally, take optional parenthesis as an example
  • ! and ? methods suffixes are a nice standard for communicating intent
  • return optional
  • More object focused
  • Often more readable
  • IntelliJ IDE support :)

Con’s

  • Slower
  • Less Mature

Python

Pro’s

  • Blocks via indentation more terse
  • Class methods can be easily treated as function objects
  • No need for @, @@, $ as namespaces are used
  • Method arguments can be passed by name
  • Automatically generates compiled scripts for efficiency

Con’s

  • pass required for empty blocks
  • Parenthesis required on method calls
  • self required as first argument to methods
  • return required
  • Verbose import statements, e.g. from package.subpackage.module import class, class.method.
  • Why import an individual method or variable?!
  • Is from datetime import datetime DRY?!
  • Less object focused, attributes are also first class citizens
  • Method documentation (docstring) within method doesn’t aid readability
  • Method default values are only evaluated once and reused in subsequent calls
  • Non-OO approach to sequence manipulation and list comprehensions with methods such as map, del, sort and sorted
  • Dictionaries throw an exception when key not found
  • No concept of scope, class internals completely exposed. Use convention (such as underscore prefix) to suggest scope
  • Ruby has Rake and Python has ?!

Weird stuff

  • zip is an unusual name for iterating over multiple sequences
  • Comparison chaining is unorthodox, i.e. 1 < 2 == 2
  • ‘Isn\’t’ produces the string “Isn’t”. However ‘Isn\’t\”‘ produces the string ‘Isn\’t”‘. In the latter case a backslash remains and the start and end quotes are different.

Similarities

Other discussions of Ruby vs. Python:

You can leave a response, or trackback from your own site.

10 Responses to “Contrasting Python and Ruby”

  1. Adrian Holovaty Says:
    May 4th, 2007 at 3:47 am

    A lot of your Python “cons” are highly subjective. Personally, I’d rate a lot of them as “pros” — I find the Python import mechanism particularly elegant, and a lot of the Python “requirements” you tend to dislike are, in my opinion, invaluable.

    Isn’t it great that both languages exist, so people can be productive in a language that suits their own tastes?

  2. blondie Says:
    May 4th, 2007 at 1:17 pm

    Thanks for commenting Adrian.

    I completely agree that this is a subjective post, biased by my greater experience with Ruby and to a lesser extent Java.

    But is it such a good thing these languages co-exist? It’s been said that these languages effectively serve the same purpose, so why the competitiveness? Perhaps it’s because natural selection is at play.

    I consider it somewhat disturbing that choosing between two languages degenerates to which one ‘feels nicer’. Then again, I guess that’s what the whole concept of CLR’s is all about.

    I fear that the time spent by their core development teams intepreting the language and providing cross-platform support is:

    • Going to go the way of the Dodo when CLR’s dominate
    • Somewhat wasted given another language serves the same niche
  3. Khamsouk Souvanlasy Says:
    May 6th, 2007 at 2:19 am

    I can see where you are coming from in terms of the efficiency perspective: why have two teams working on the same problem? Why re-invent the wheel?

    But a large part of programming is the creative process. We need to work with the tools that we feel most productive and comfortable with. For some it’s Python, and others it’s Ruby. In any case, they’re both better than Java ;)

    It’s also about community and idealogy: Matz had his own itch to scratch in terms of what he felt made a good language. It just so happens that those same itches were shared by a whole lot of other people.

    CLR’s may dominate in the future, but what about the here and now? In any case I’d still prefer a VM tuned to a language than several, not just from a performance/bloat perspective but because I think it’s easier for that implementation to improve on it’s own or start over e.g. Yarv.

  4. Justin Grant Says:
    July 13th, 2007 at 9:29 am

    Matthew: nice points even though they are subjective.

    Adrian: guess it depends on your highly subjective definition of productivity.

  5. ungrasping it all : Red vs. Blue Says:
    July 13th, 2007 at 9:36 am

    […] a somewhat biased comparison of Ruby and Python but still some good […]

  6. Justin Grant Says:
    July 15th, 2007 at 8:55 am

    To poster #1: Is it possible that your idea of a what’s ‘productive’ is highly subjective too ?

  7. mykhal Says:
    September 21st, 2007 at 2:10 am

    - What do you mean by that python requires return ? Yes, where you do expect the return value, there you have to use return. It’s different in ruby ? It uses some perlish $_ ?

    - There is not any backslash in ‘Isn\’t\”‘, it’s just a representation.. try to print it

    - a.method() is the method call, and a.method is the method object/function, which we can work with, ruby knows only calls, that’s why there are no parentheses needed

    I see another things in python partially confusing, for example some inconsistency with mutability of different variable types (strings are immutable); or range boundary: range(1, 2) == [1]

  8. blondie Says:
    September 25th, 2007 at 8:47 pm

    Thanks for the comment mykhal.

    Sure Ruby doesn’t require return. The result of the last operation in a Ruby method is returned by default.
    Thus:

    def some_method
  ""
end

    Returns “”

    Also, you are correct regarding the formatting of ‘Isn\’t\”‘, although that is a particularly strange way to format the String.

    Nonetheless my confusion stands; why is the \’ portion of the String represented as \’, but the \” portion as “ ?

  9. Joe Says:
    January 4th, 2008 at 7:54 am

    Some interesting comments above. I just have one more to add. You ask “Is ‘from datetime import datetime’ DRY?”

    Well, yes it is. The first ‘datetime’ is the name of the module, the second is a datetime within that module. You haven’t repeated yourself, because you’ve referred to two different things. It’s a slightly odd naming convention that’s been chose, but hardly a con of the language as a whole.

  10. Daniel Says:
    January 16th, 2008 at 1:51 am

    I concur with Adrian. Many of Python’s so-called “cons”,are in my opinion, pros.

Leave a Reply