[greggraham]

I currently use Python and Django for the following reasons: 1) Coworker familiar with Python 2) I had an easier time understanding the mechanics of Django than I did Rails 3) Some libraries I needed were only in Python

However, from a language point of view, I have a slight preference towards Ruby. Here are some things I like: 1) More consistent commitment to object paradigm, e.g. all function calls are actually method calls on an object. In Python, everything is an object, but sometimes you use methods, and sometimes you don't, e.g. list.pop() vs. len(list). 2) I think blocks are very handy. 3) I like the more Perlish regex syntax. 4) There is a cleverness to Ruby that might not be the best thing for a corporate environment, but it makes it fun.

So, if I was writing code just for myself, I might choose Ruby over Python, assuming performance and library support were sufficient.

[ubernostrum]

Humor me for a moment, because I've been asking this question of many people for a long time and have never yet gotten a straight answer.

Why is len() always the thing people pick on? Why is it always "Python uses len(obj) instead of obj.len()", and never "Python uses str(obj) instead of obj.str()", or any of the various polymorphic built-ins like sum()? I've seen this so many times now that I'm honestly quite curious about it.

Also:

"More consistent commitment to object paradigm, e.g. all function calls are actually method calls on an object."

Every function call in Python is always an invocation of a method on an object, even if it doesn't look like it. len(), of course, delegates to a method on the object. But even standalone functions are method calls. Try this:

>>> def add(x, y):

... return x + y

...

>>> add(3, 5)

8

>>> import types

>>> types.FunctionType.__call__(add, 3, 5)

8

The last couple lines there are what's really going on when you call the function.

(also, just as Ruby's "built-in" functions are really methods on Kernel which is made available globally, Python's "built-in" functions really exist in a module that's made available globally (and __builtins__ is its name)

[bendotc]

I'm starting to feel like a broken record here, but whenever anyone wants to pick in "str" I find myself compelled to point out:

  >>> type(str)
  <type 'type'>

That is to say, str isn't a magical function, it's a type, and "str()" is how you call that type's constructor. How is this not somehow object oriented?

Of course, even if str was a function and not a constructor, it would be an object factory which delegates to its argument via a well defined interface (the __str__ method). OOP doesn't have to mean everything-is-an-object.

[earthboundkid]

Even without going to the trouble of importing types, every Python callable has an __call__ method. Including the __call__ method:

    >>> def f():
    ...  print("Helllo __call__")
    ... 
    >>> f.__call__.__call__.__call__.__call__()
    Helllo __call__

Don't use this in real life though, there's a performance penalty.

[ubernostrum]

Of course, there's also the singleton that always returns itself:

  >>> recursive = lambda: recursive

[seanodonnell]

len(list) is actually a shortcut for calling list.__len__() , any object that implements the __len__ method is therefore compatible with it. So in practice, len is in fact a method call. Almost every python function that operates on objects is just a similar shorthand.