Firstly, I chose to look at Python for several reasons. One of the prime ones is the (many) conversations I have had with OO purists, Java zealots and the like about how "poor" the languages I prefer to use in my daily toolkit. Primarily I'm using things like VBS to automate anything I'm doing on Windows, PHP for anything I'm doing cross platform/on the web (outside of the day job) and other miscellaneous tools for other jobs.
The objections are mainly of the religious type. VBS is a "Microsoft Abomination" and doesn't support Object Orientation beyond a COM objects and really basic class behaviour (no inheritance, interfaces etc). For many people, this is a major issue. Personally, I'm a pragmatist. People have said [1] that Python allows you to work in the way that is most efficient to get the job done. It gives you tools to do whatever you need, in a way that suits the task at hand.
Generally, this would be something I would say is A Good Thing, if there really was one language that gave me the tools to do everything I want to do as a programmer in the most efficient way for that task, I would be much happier and wouldn't be coding in half a dozen languages every day.
However, I'm coming at this from the critisism of my prefered tools for doing exactly this, PHP is a very flexible language, it allows you to do fully OO code (in PHP5 at least) or fully procedural. It gives you tools to do pretty much anything, and can easily be extended with a new, um, extension. But, the counter to this argument I'm always given from the religious language debates is exactly too much rope to hang yourself with. Hence my comments about dirty code etc [2].
I was given to beleive that Python was a very powerful language, where writing the code that it first occurs to you to write turns out to be the way to do it [3]. Where the code was clean and easy to understand. Where Everything is an Object. And remember, this is in debates with OO Zealots.
Nirvana? The promised land? A language that is so obvious it doesn't take effort to code? Where good style and maintainable readable efficient code just happens? Sounds pretty good so I decided to take a look.
Now, the kinds of things I'm likely to want to do from Python would benefit heavily from an OO approach. Code reuse. Standard Design patterns. Frameworks. All the stuff that will make me quickly build my standard massive collection of libraries (well classes in this case) to snap together to solve any problem. So I started to look into it.
I've been easily convinced (see I am listening [a]) that the procedural modules are not a problem. Essentially the module is a namespace, a namespace is an object[b], and thus it's a hell of a lot less pain than having a static method in a wrapper class for the need to be class driven. It's close enough to OO principles to work in a very practical way.
Now, my biggest bugbear, to be honest, is the del thing. Now, del may be syntactic sugar[5] for a standard interface that any deletable object supports. Not wanting to get too bogged down into this really, but I feel the need to justify exactly why I think it's wrong and in fact bad.
You have an object, that object has a set of methods. For most of it's behaviour, that object provides an OO set of methods. But to remove an item from a dictionary, rather than having a remove item method or anything like that, you use the standard destructor sugar. (Ignoring the fact, the most obvious thing to do is d.removeitem("key") or something similar, the expected syntax in an OO language.)
So, we have del, which is sugar for calling a destructor. Why? What's wrong with object.free or something similar? Consider it an operator [6]? I guess, it's kind of similar to a not operator [7]. Not object. Del object.
But why implement it that way? Under the covers, regardless of how you choose to code, Python is OO [8]. So why not just a standard interface method that objects that could be del'd implement? I guess it is, if it just calls __delitem__ only, it seems it calls different things on different objects, so it's a convinience syntax for implementations of numerous interfaces. Which seems to be bad. Why can't they have a consistent interface?
More horrible, to me, is the non obviousness of the code I think. del d, free's the dictionary, but del d["key"] removes a key value pair from the dictionary it does not, as all sanity (IMHO) would indicate, free the object pointed to by key leaving key pointing to a "None" value. It does something less obvious. Which is never good. And still think d.free and d.remove("key") makes far more sense.
My post wasn't intended to get into a big debate of the above, which I have probably just poured more fuel on the flames on rather than explained my position better, but such is the religious nature of language design. I'll steer well clear of choice of editor ;-)
What I want to know really, is how much more of this kind of thing goes on in Python, where does it have these questionable language decisions? How much of an issue are they in practice (and I'm guessing the answer from Python fans will be not at all, but...)? How often do these things result in bad code (even if it is surprisingly easy to replace/refactor [9])? And how can I put my cow-workers back in their boxes ;-)
I'm looking at Ruby too, which does appear to be Pure OO. Methods on literals? Cracking!
References
[1] Various comments (in no particular order, and I probably missed them) 1 2 3 4 and so on...
[2] For example
[3] ESR Article
[4] The Python Mantra?
[5] Here refering to here
[6] here
[7] Reasonable Operator Definition
[8] Here
[9] Here
Stuff I edited in later and didn't want to renumber everything...
[a] Here
[b] Here
