On Fri, Feb 8, 2013 at 9:48 AM, Rick Johnson <rantingrickjohn...@gmail.com> wrote: > On Friday, February 8, 2013 9:16:42 AM UTC-6, Steven D'Aprano wrote: >> Rick Johnson wrote: > Just because /everything/ in Python is an object does not mean that Python is > 100% OOP.
The whole idea of "make everything an object" is possibly a misguided sense of puritanism anyway. I wouldn't harp on that point to much. But I really like your other developments. Like the following > If so, Python would have a supertype called "Collection" that wold define all > methods that operate on collections. Some of these include: > > len, any, all, length, isempty, __getitem__, __setitem__, etc... I think this is a great idea and fixes a language wart which put irrelevant methods into the builtin namespace. > Then any collection subtype would inherit from this supertype and get the > methods for free. Yes. OOP encapsulation. But I question whether strings should be considered collections. This is a spurious usage issue, not something in an integrated object model (see below on what I mean). >> And a *really* smart language designer will have realised this ahead of >> time, and designed the language to encourage the use of protocols like >> this, instead of insisting on the slavish application of obj.method syntax. > Using built-in functions to operate on objects is foolish because you are > placing extra burden on the programmer to know which /functions/ work with > which /types/. The *only* functions that should be global are the kind that > will work on *ANY* object. But then again, the Object type could hold these > methods! Exactly. This gets us closer to the real Python3000 that I've been waiting for.... > len, all, and any (just to name a few) only work for collections types and as > such should be methods of these types. The global functions: > > sum, len, any, all, enumerate, map, max, min, reversed, sorted, zip > > can only be applied to sequence types, or subtypes of a sequence type. So > using a /real/ OOP paridigm we would do the following: > > ## START TRUE OOP PARIDIGM ## > [[snip]] This is a great start, I think, but I think it's time to really re-evaluate the whole data model again. Before Python was trying to "have everything", and have the flexibility to adapt for everyone, but sometimes I think there's too much flexibility and options and it leads to sloppiness. I would argue it's time for a refactor and re-think the object model. > class Object(SuperType): > def dir > def help > def id > def isinstance?(Type) > def issubclass?(Type) > def super > def type I like the general line-of-thought, but some of these are questionable. I think it's essential to have help() outside any class -- the built-in, global methods serve an important purpose of setting the culture for a language, and help, (and my proposed test()) builtin are part of (or would be) the community. > class SequenceBase(Object): > def sum > def filter(proc) > def map > def max > def min > def reverse > def reduce(proc) Here again, you see how the early python community put these in the global namespace because of the bias that they had such (admittedly() cool builtin collection types in the language. But now, it's interesting to reconsider these ideas. > ## END TRUE OOP PARIDIGM ## > > You see, 100% OOP uses encapsulation, inheritance, sub-typing, etc, etc... > But most fundamental to OOP is interface (methods belonging to objects), not > global functions applied to objects in some haphazard fashion that some > self-appointed dictator pull from his backside due to his fear of true OOP > style! That's not quite fair to the BDFL; you're criticizing the community that made Python great. That, of course, doesn't mean that it's still logical to keep them out there in the global scope, exposed for all to see. > Python is not 100% OOP. Heck you cannot fairly apply a specific percentage > level because Python's level of OOP is defined by each user of the language. > The best way to describe Python is as promiscuous language who secretly longs > to be 100% OOP, and to fulfill this fantasy it cross-dresses in OOP lingerie > on the weekends. That's a funny quote, besides its questionable accuracy, but your initial sentences point out that having a unified data model might actually be of use. A unified data model does for data what lexical definitions and parsers do for code: organize it in a well-defined way that is a *complete* specification for all possible data organizations. (But see my other posts about that.... ;^) Mark Tacoma, Wa -- http://mail.python.org/mailman/listinfo/python-list
