This post originated from an RSS feed registered with Python Buzz by Ian Bicking. Original Post: Hash table accused of impersonating OO Feed Title: Ian Bicking Feed URL: http://www.ianbicking.org/feeds/atom.xml Feed Description: Thoughts on Python and Programming. Latest Python Buzz Posts Latest Python Buzz Posts by Ian Bicking Latest Posts From Ian Bicking

From a post by Ted Leung came some links to a Python to Scheme translator that was presented at the 2003 Scheme Workshop.

I found this comments on Python interesting:

Here is my take on Python after working through this "exercise": Python pretends to be an OO-based language yet it is really a hashtable-based that creates an illusion of OO-oriented programming. For simple programs, this works all right but most Pythonistas seem to actually exploit the translucent nature of objects and classes. It is a hopeless task to reason about modules or program pieces in this language. (source)

It is an interesting comment, though certainly greatly biased because the author came at it from an implementation perspective, rather than the perspective of writing Python code. Though really I would say (to quote import this) Namespaces are one honking great idea -- let's do more of those!. Really all the hash tables (dictionaries) are namespaces, and all the namespaces look the same, and none of them are magical.

A surprising number of languages -- Scheme included (where they can't decide on a-lists or hash tables) -- make dictionaries way too difficult. Considering that I use dictionaries almost as much as lists, it's really other languages that should be answering for their deficiencies.

But anyway, I don't actually disagree about what he has to say. Well, you can reason about code, just not in an analytic, programmatic sort of way (which is what he wants to do, because he's writing a compiler). I guess I'm not as concerned, because I prefer programmer empowerment to compiler empowerment (and there are more than enough languages out there that are biased to the compiler, probably because the first programmer is usually a compiler writer ;)

Another comment:

It reminds me of Lisp in its extreme youth where the value and function cells were kept on the symbol property list and people felt free to manipulate them in undisciplined ways. Its very flexible and powerful, but the lack of discipline makes it impossible to reason about. Since those days we've learned that we can achieve the same results in a structured manner. Python is still young. (source)

I'm sympathetic to things that will make a program easier to understand, and I can see how manipulating the object model (which is so very easy in Python) can be an issue. There are greater sins (like Acquisition), but cleverness is a dangerous thing, and there is a great deal of room for cleverness in Python. (Though Lispers aren't one to talk, what with their All Powerful macros) I myself have been prone to cleverness from time to time. I sometimes think the best libraries are the ones that seem most simplistic, sometimes painfully explicit -- they are the easiest to understand, and the least likely to surprise. But then, I tend not to write libraries like that, so there's obviously some disconnect in my thinking.