In Ruby's REPL, i can interrogate any object for the methods it has on it (unless it's using method_missing in horrible ways), effectively allowing me to list out it's API.

As far as i'm aware, that's not the case in python's REPL, or at least, i was never able to figure out how to do it (i will fully admit to not being a python expert, but at the same time i'm not a n00b either).

Also, please note, i'm not dissing Python, i like python (just not as much as i like Ruby).

I stand by my argument about OO. It should be possible to quickly and succinctly describe what OO is supposed to do, and demonstrate how your language uses them to bundle up functionality. If you can't do that, you're doing it wrong.

Objects should not get in the way of being able to write code.

Lastly, please don't put words in my mouth. I don't think monkeypatching is relevant to the discussion, and the fact that len is not a method on objects is weird, but ultimately inconsequential.

    dir(__builtins__) 

    dir(list)

    dir([])

etc… the same caveats apply to dir with getattr etc as to method_missing. additional caveat i dont care to test; it may not work on an old style class instance.

help has its __repr__ defined to tell you how to use it. It will allow you to read the doc strings for a namespace, object or function. However i prefer to run 'pydoc -p 8888' in my projects top level; this will start an http server on port 8888 that lets you interactively browser your projects docstrings and all the modules on its pythonpath.

Hope that helps

   dir( object )

Python is missing encapsulation and message passing. It's object model seems to be similar to something like PHP or JavaScript: objects are essentially hashes. In practice, that's not a huge deal, but they aren't quite the same.

This is not important for beginning programmers, but for programmers thinking about their toolset more information can only help.

The Python equivalents are namespaces and methods.

Python doesn't subscribe to protecting the code from the programmer, like some of the more BSD languages. Python does encapsulate objects as a single namespace but it's a transluscent encapsulation."

From: http://www.voidspace.org.uk/python/articles/OOP.shtml

What would you suggest as a better alternative, outside of a purely functional approach? Just as an example, suppose that Java's LinkedList class didn't have a cached size and that instead it went and iterated its elements to calculate its size each time someone asked for it. I might write a wrapper around LinkedList with two private variables, the LinkedList and an int to cache its size in. Then I would update the int each time an operation was performed on my member list. If I can't make those two members private, how can I ensure that no one accidentally updates the list without updating the size, or vice-versa. It mightn't be an unreasonable mistake for someone to think calling mylist.size = 0 would empty the list. What is the 'safe' way of constructing this concept?

Conventions. In Python, for instance, all private fields and methods start with a double underscore, i.e., '__'. This is merely a convention, outlined in PEP8. Documentation tools don't pick up "private" fields. Even when they do, they don't list them in the same section as the public fields.

You could argue about the safety of this approach, but at some point you have to let go of the training wheels and let programmers make their own judgments.

http://diveintopython.org/object_oriented_framework/private_...

Does that count for encapsulation?