Have you seen the (*very* *early* *experimental*) set of ABCs that I started in sandbox/abc/abc.py ?
On 4/14/07, Talin <[EMAIL PROTECTED]> wrote: > Part of the reason why I haven't volunteered to write a PEP for ABC's is > because I don't feel that I understand the various proposals and the > background discussion well enough. However, it occurs to me that writing > the rationale section of a PEP can often be the hardest part, and I > think I understand the issues well enough to write that preface. So > here's my contribution: > > --- > > In the domain of object-oriented programming, the usage patterns for > interacting with an object can be divided into two basic categories, > which are 'invocation' and 'inspection'. > > Invocation means interacting with an object by invoking its methods. > Usually this is combined with polymorphism, so that invoking a given > method may run different code depending on the type of an object. > > Inspection means the ability for external code (outside of the object's > methods) to examine the type or properties of that object, and make > decisions on how to treat that object based on that information. > > Both usage patterns serve the same general end, which is to be able to > support the processing of diverse and potentially novel objects in a > uniform way, but at the same time allowing processing decisions to be > customized for each different type of object. > > In classical OOP theory, invocation is the preferred usage pattern, and > inspection is actively discouraged, being considered a relic of an > earlier, procedural programming style. However, in practice this view is > simply too dogmatic and inflexible, and leads to a kind of design > rigidity that is very much at odds with the dynamic nature of a language > like Python. > > In particular, there is often a need to process objects in a way that > wasn't anticipated by the creator of the object class. It is not always > the best solution to build in to every object methods that satisfy the > needs of every possible user of that object. Moreover, there are many > powerful dispatch philosophies that are in direct contrast to the > classic OOP requirement of behavior being strictly encapsulated within > an object, examples being rule or pattern-match driven logic. > > On the the other hand, one of the criticisms of inspection by classic > OOP theorists is the lack of formalisms and the ad hoc nature of what is > being inspected. In a language such as Python, in which almost any > aspect of an object can be reflected and directly accessed by external > code, there are many different ways to test whether an object conforms > to a particular protocol or not. For example, if asking 'is this object > a mutable sequence container?', one can look for a base class of 'list', > or one can look for a method named '__getitem__'. But note that although > these tests may seem obvious, neither of them are correct, as one > generates false negatives, and the other false positives. > > The generally agreed-upon remedy is to standardize the tests, and group > them into a formal arrangement. This is most easily done by associating > with each class a set of standard testable properties, either via the > inheritance mechanism or some other means. Each test carries with it a > set of promises: it contains a promise about the general behavior of the > class, and a promise as to what other class methods will be available. > > This PEP proposes a particular strategy for organizing these tests known > as Abstract Base Classes, or ABC. ABCs are simply Python classes that > are added into an object's inheritance tree to signal certain features > of that object to an external inspector. Tests are done using > isinstance(), and the presence of a particular ABC means that the test > has passed. > > Like all other things in Python, these promises are in the nature of a > gentlemen's agreement - which means that the language does not attempt > to enforce that these promises are kept. > > _______________________________________________ > Python-3000 mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-3000 > Unsubscribe: > http://mail.python.org/mailman/options/python-3000/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
