fix three trivial typos.
This commit is contained in:
parent
6ba0c5ab1f
commit
a9f047fab8
|
@ -158,7 +158,7 @@ Specification of the class-based introspection API
|
|||
|
||||
In the discussion below, I distinguish two kinds of objects:
|
||||
regular objects (like lists, ints, functions) and meta-objects.
|
||||
Types and classes and meta-objects. Meta-objects are also regular
|
||||
Types and classes are meta-objects. Meta-objects are also regular
|
||||
objects, but we're mostly interested in them because they are
|
||||
referenced by the __class__ attribute of regular objects (or by
|
||||
the __bases__ attribute of other meta-objects).
|
||||
|
@ -225,7 +225,7 @@ Specification of the class-based introspection API
|
|||
meta-objects, the bases. An absent __bases__ is equivalent to
|
||||
an empty sequence of bases. There must never be a cycle in the
|
||||
relationship between meta-objects defined by __bases__
|
||||
attributes; in other words, the __bases__ attributes define an
|
||||
attributes; in other words, the __bases__ attributes define a
|
||||
directed acyclic graph, with arcs pointing from derived
|
||||
meta-objects to their base meta-objects. (It is not
|
||||
necessarily a tree, since multiple classes can have the same
|
||||
|
@ -555,7 +555,7 @@ C API
|
|||
- But now for a more complicated case. The approach described
|
||||
above is suitable for most built-in objects such as lists,
|
||||
strings, numbers. However, some object types have a dictionary
|
||||
in each instance that can store arbitrary attribute. In fact,
|
||||
in each instance that can store arbitrary attributes. In fact,
|
||||
when you use a class statement to subtype an existing built-in
|
||||
type, you automatically get such a dictionary (unless you
|
||||
explicitly turn it off, using another advanced feature,
|
||||
|
|
Loading…
Reference in New Issue