9

I remember that at one point, it was said that Python is less object oriented than Ruby, since in Ruby, everything is an object. Has this changed for Python as well? Is the latest Python more object oriented than the previous version?

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
nonopolarity
  • 146,324
  • 131
  • 460
  • 740
  • 7
    In Python, everything's an object. What source did you read? Can you provide a URL or a quote? – S.Lott May 21 '09 at 18:59
  • 5
    @S.Lott — He's right; in fact, the Ruby "About" page still recounts that as the origin of Ruby. Matz is quoted as saying: “I wanted a scripting language that was more powerful than Perl, and more object-oriented than Python.” http://www.ruby-lang.org/en/about/ – Brandon Rhodes May 21 '09 at 19:27
  • I have the same perception. Python being more "structured" and Ruby born to be pure OO since its inception. But I cannot tell why.. – OscarRyz May 21 '09 at 19:34
  • In Ruby some things are not objects. They are disguised as objects, and (mostly) act as objects, but they aren't. Don't believe me? Try to define a singleton method for the number 3 (`a = 3; def a.foo ; end`) and the sharp edges of a non-object will show. – Wayne Conrad Mar 02 '10 at 22:00
  • @Wayne, doesn't that simply mean that you can't define a singleton method on a number? how does that demonstrate that numbers are not objects? :) – horseyguy Sep 08 '10 at 11:33
  • 1
    @banister, Yours is a different way to look at it than I had considered, and not necessarily wrong. From the Ruby source, we know that most variables are held as references which essentially point to the memory containing the object, but for some types, such as Fixnum, the value of the object is in the reference itself. That's why you can't define a singleton on 4: There's no normal instance to which the singleton can be attached. Rather than consider "4" as an object with special restrictions, it seems to me a "non object" made to look _mostly_ like an object. – Wayne Conrad Sep 08 '10 at 14:15

6 Answers6

40

Jian Lin — the answer is "Yes", Python is more object-oriented than when Matz decided he wanted to create Ruby, and both languages now feature "everything is an object". Back when Python was younger, "types" like strings and numbers lacked methods, whereas "objects" were built with the "class" statement (or by deliberately building a class in a C extension module) and were a bit less efficient but did support methods and inheritance. For the very early 1990s, when a fast 386 was a pretty nice machine, this compromise made sense. But types and classes were unified in Python 2.2 (released in 2001), and strings got methods and, in more recent Python versions, users can even subclass from them.

So: Python was certainly less object oriented at one time; but, so far as I know, every one of those old barriers is now gone.

Here's the guide to the unification that took place:

http://www.python.org/download/releases/2.2/descrintro/

Clarification: perhaps I can put it even more simply: in Python, everything has always been an object; but some basic kinds of object (ints, strings) once played by "different rules" that prevent OO programming methods (like inheritance) from being used with them. That has now been fixed. The len() method, described in another response here, is probably the only thing left that I wish Guido had changed in the upgrade to Python 3.0. But at least he gave me dictionary comprehensions, so I won't complain too loudly. :-)

Brandon Rhodes
  • 83,755
  • 16
  • 106
  • 147
  • Did Guido ever give a reason why he left out the len() method in 3.0? – James McMahon May 21 '09 at 20:08
  • Yes, there is an article somewhere. Basically his reasning was that len(my_list) is more straigthforward to read than my_list.len(). – nikow May 21 '09 at 20:23
  • 6
    @nemo, basically he said that len(x) is guaranteed to return an int, whereas x.len() has no such guarantee. And, that he originally liked the way it looks better. (found the emails: http://mail.python.org/pipermail/python-dev/2008-January/076575.html http://mail.python.org/pipermail/python-dev/2008-January/076612.html) – JimB May 21 '09 at 20:33
  • 6
    Oh, wow. A really **great** blog post on the subject of why `len()` is a function instead of a per-object attribute: http://lucumr.pocoo.org/2011/7/9/python-and-pola/ – Brandon Rhodes Aug 03 '11 at 19:07
12

I'm not sure that I buy the argument that Ruby is more object-oriented than Python. There's more to being object-oriented than just using objects and dot syntax. A common argument that I see is that in Python to get the length of a list, you do something like this:

len(some_list)

I see this as a bikeshed argument. What this really translates to (almost directly) is this:

some_list.__len__()

which is perfectly object oriented. I think Rubyists may get a bit confused because typically being object-oriented involves using the dot syntax (for example object.method()). However, if I misunderstand Rubyists' arguments, feel free to let me know.

Regardless of the object-orientation of this, there is one advantage to using len this way. One thing that's always annoyed me about some languages is having to remember whether to use some_list.size() or some_list.length() or some_list.len for a particular object. Python's way means just one function to remember

Jason Baker
  • 192,085
  • 135
  • 376
  • 510
  • 2
    Why not expose .len() directly off of list then? I think you can't completely divorce OO design from the syntax, because the syntax, to a large extent, defines your code paradigm. some_list.len() is OO because you are thinking about the list as an object that will be able to tell you what its length is. len(some_list) is not OO, regardless of what it translates to under the covers. – James McMahon May 21 '09 at 19:09
  • 9
    Sorry. Syntax and OO have nothing to do with each other. Python objects can have non-object syntax. They're still objects. – S.Lott May 21 '09 at 19:15
  • @nemo - I'd disagree with your comment, but such is life. There is one advantage to using Python's syntax outside the oo-ness. I edited that in to my answer. – Jason Baker May 21 '09 at 19:21
  • 3
    object oriented includes both syntax and data model, but object based includes data model and if possible syntax sugar. – mtasic85 May 21 '09 at 19:25
  • 1
    @S.Lott, if your not treating an object as an object by calling methods off that object to deal with said object. You are not programming in the OO paradigm. That is what I meant by syntax, the ability to treat objects as objects. As mtastic said, OO is a combination of syntax and the underlying data model. If you have a dog object and you pass it to a method run(dog), then not programming in a OO style, which would be dog.run(). The dog is told to run directly. Don't confuse what I'm saying for putting any paradigm down, they all have their place, but by definition, run(dog) is not OO. – James McMahon May 21 '09 at 19:43
  • 1
    Since len(list) invokes a method of the list, I don't see where the object-orientation vanished. I am treating the list as an object, since everything's an object. This isn't C++. – S.Lott May 21 '09 at 19:48
  • I think we are confusing the data type with the paradigm. What I am talking about when I say syntax is the application of paradigm. For instance, in Java, where you have primitives and objects. You can still treat and object (like a String) in a non OO way. Like normalize(string) versus string.normalize. String in both case is an object, but only in the second case are you using the OO paradigm, where the first is more like C style procedural code. – James McMahon May 21 '09 at 19:56
  • 2
    Forgive me, I'm not a python expert, but I don't see much discussion of true "object orientedness". Is len(some_list) polymorphic in python? Can I subclass off of that list and override the len method? Just curious. – Ogre Psalm33 May 21 '09 at 20:07
  • 3
    @Ogre Psalm33 - Yes. If you override the __len__ method of the object, it will control what the len function gets. – Jason Baker May 21 '09 at 21:32
  • 1
    I don't think dot notation and other common syntaxes are essential to the concept of OOP. Consider: multiple dispatch (multimethods) http://en.wikipedia.org/wiki/Multiple_dispatch – Doug May 22 '09 at 04:25
7

Although this is not properly an answer... Why do you care about Python being more or less OO? The cool thing about Python is that it's pythonic, not object oriented or funcitonal or whichever paradigm that is fashionable at the moment! :-)

I learnt to program with Java and Object Orientation, but now I don't give a sh.t about it because I know that OOP is not the solution to all the problems (indeed, no single paradigm is).

see:

fortran
  • 74,053
  • 25
  • 135
  • 175
2

Hold on, both Ruby and Python are object oriented. Objects are objects. There isn't more object oriented 'comparison function' that will lead you to the better one. Syntax is not only thing which makes some language to look like object oriented one, but also data model.

Objects are Python’s abstraction for data. All data in a Python program is represented by objects or by relations between objects. (In a sense, and in conformance to Von Neumann’s model of a “stored program computer,” code is also represented by objects.) http://docs.python.org/reference/datamodel.html

mtasic85
  • 3,905
  • 2
  • 19
  • 28
2

This is an incorrect belief.

See my previous answer here for more in-depth explanation:

Is everything an object in python like ruby?

Why not expose .len() directly off of list then? I think you can't completely divorce OO design from the syntax, because the syntax, to a large extent, defines your code paradigm. some_list.len() is OO because you are thinking about the list as an object that will be able to tell you what its length is. len(some_list)

.len() is available directly off the list. It is available as __len__(). len() is a function object. You can see all its methods with dir(len). While I do not know why Guido decided to make the __len__() method longer, it does not change the fact that all of those are still objects.

Community
  • 1
  • 1
Unknown
  • 45,913
  • 27
  • 138
  • 182
  • Thanks for the direct reply. I though calling __method__ directly was discouraged in Python as __ was shorthand for private. I think I am just confusing the __ with something else. – James McMahon May 21 '09 at 19:47
  • Ah __method is distinct from __method__, the former is private (unenforced) and the latter is "special system functions with pre-defined behavior". – James McMahon May 21 '09 at 20:06
1

I have the same "perception" perhaps derived from this:

Why was python created in the first place:

It occurred to me that a scripting language with a syntax like ABC [...] would fill the need

An Interview with the Creator of Ruby:

"I wanted a scripting language that was more powerful than Perl, and more object-oriented than Python

I know that perception is not the same as reality. Both Python and Ruby are great programming languages and both are very OO.

OscarRyz
  • 196,001
  • 113
  • 385
  • 569