Clean up trailing whitespace.
This commit is contained in:
parent
a37f0eda27
commit
cbda3c2812
82
pep-3119.txt
82
pep-3119.txt
|
@ -32,65 +32,65 @@ This is a proposal to add Abstract Base Class (ABC) support to Python
|
|||
Rationale
|
||||
=========
|
||||
|
||||
In the domain of object-oriented programming, the usage patterns for
|
||||
interacting with an object can be divided into two basic categories,
|
||||
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
|
||||
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
|
||||
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
|
||||
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
|
||||
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
|
||||
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
|
||||
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
|
||||
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
|
||||
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
|
||||
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.
|
||||
|
||||
|
||||
|
|
Loading…
Reference in New Issue