[Python-checkins] r54869 - peps/trunk/pep-3119.txt

[guido.van.rossum]

Author: guido.van.rossum
Date: Wed Apr 18 19:43:05 2007
New Revision: 54869

Modified:
   peps/trunk/pep-3119.txt
Log:
Clean up trailing whitespace.


Modified: peps/trunk/pep-3119.txt
==============================================================================
--- peps/trunk/pep-3119.txt	(original)
+++ peps/trunk/pep-3119.txt	Wed Apr 18 19:43:05 2007
@@ -32,65 +32,65 @@
 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.