[Python-3000] An introduction to ABC's

[Guido van Rossum]

Have you seen the (*very* *early* *experimental*) set of ABCs that I
started in sandbox/abc/abc.py ?

On 4/14/07, Talin <talin at acm.org> 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
> Python-3000 at python.org
> 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/)