On Mon, May 11, 2015 at 11:46 AM, zipher <dreamingforw...@gmail.com> wrote: >> > 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. >
Please take care of your quoting. You just quoted two other posts, and I have no idea who said things without going and digging in the archive. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
