Merge pull request #44 from zhangyangyu/master
fix a few typos of PEP 252, 253, 367, 3135
This commit is contained in:
commit
82ee13e555
|
@ -192,7 +192,7 @@ Specification of the class-based introspection API
|
|||
|
||||
Typically, the value of an attribute with a given name is the
|
||||
same object as the value corresponding to that name as a key in
|
||||
the __dict__. In othe words, obj.__dict__['spam'] is obj.spam.
|
||||
the __dict__. In other words, obj.__dict__['spam'] is obj.spam.
|
||||
(But see the precedence rules below; a static attribute with
|
||||
the same name *may* override the dictionary item.)
|
||||
|
||||
|
@ -395,7 +395,7 @@ Static methods and class methods
|
|||
'c.foo' and an unbound method object for 'C.foo'.
|
||||
|
||||
(XXX Barry suggests to use "sharedmethod" instead of
|
||||
"staticmethod", because the word statis is being overloaded in so
|
||||
"staticmethod", because the word static is being overloaded in so
|
||||
many ways already. But I'm not sure if shared conveys the right
|
||||
meaning.)
|
||||
|
||||
|
|
|
@ -267,7 +267,7 @@ Making a type a factory for its instances
|
|||
|
||||
For some objects, tp_new() may return an existing object. For
|
||||
example, the factory function for integers caches the integers -1
|
||||
throug 99. This is permissible only when the type argument to
|
||||
through 99. This is permissible only when the type argument to
|
||||
tp_new() is the type that defined the tp_new() function (in the
|
||||
example, if type == &PyInt_Type), and when the tp_init() slot for
|
||||
this type does nothing. If the type argument differs, the
|
||||
|
|
|
@ -229,7 +229,7 @@ The reference implementation assumes that it is being run on Python 2.5+.
|
|||
except ValueError:
|
||||
sv_pos = None
|
||||
|
||||
# Check if the callvar 'super' keyword is already present
|
||||
# Check if the cellvar 'super' keyword is already present
|
||||
try:
|
||||
sc_pos = list(co.co_cellvars).index('super')
|
||||
except ValueError:
|
||||
|
@ -509,7 +509,7 @@ super(self, \*args) or __super__(self, \*args)
|
|||
|
||||
This solution only solves the problem of the type indication, does not handle
|
||||
differently named super methods, and is explicit about the name of the
|
||||
instance. It is less flexable without being able to enacted on other method
|
||||
instance. It is less flexible without being able to enacted on other method
|
||||
names, in cases where that is needed. One use case this fails is where a base-
|
||||
class has a factory classmethod and a subclass has two factory classmethods,
|
||||
both of which needing to properly make super calls to the one in the base-
|
||||
|
|
|
@ -157,7 +157,7 @@ super(self, \*args) or __super__(self, \*args)
|
|||
|
||||
This solution only solves the problem of the type indication, does not handle
|
||||
differently named super methods, and is explicit about the name of the
|
||||
instance. It is less flexable without being able to enacted on other method
|
||||
instance. It is less flexible without being able to enacted on other method
|
||||
names, in cases where that is needed. One use case this fails is where a base-
|
||||
class has a factory classmethod and a subclass has two factory classmethods,
|
||||
both of which needing to properly make super calls to the one in the base-
|
||||
|
|
Loading…
Reference in New Issue