> > 3.) true OOP > > Now before you go and get all "huffy" over this statement, hear me > > out. Python is the best language in the world. But it damn sure has > > some warts! "len(this)" instead of "obj.length" max(that) instead of > > [1,2,3,4,5].max(). > > As the Zen says: '[P]racticality beats purity'. Personally, I'm not > sure how a handful of convenient built-in functions make a language in > which _everything is an object_ somehow "false" OO. > > If you're really that concerned with writing "true" OO (for some > wildly variable value of "true"), there's nothing stopping you from > doing so now: > > obj.__len__()
The issue is that Python currently blurs a very powerful conceptual boundary in CS -- between the abstract space where objects and variables are held and the concrete underlying machine. By having methods like len() in your built-in namespace when it's really only relevant to objects that are types of containers, you blur one primary component of OOP: encapsulation. Mark -- https://mail.python.org/mailman/listinfo/python-list
