Conform to Barry's new PEP referencing guidelines.
This commit is contained in:
parent
e3eaa92bcf
commit
96eb7ba974
|
@ -403,7 +403,7 @@ Implementation
|
|||
here, see the file Lib/test/test_descr.py.
|
||||
|
||||
Note: the code in this branch goes beyond this PEP; it is also
|
||||
on the way to implementing pep-0253 (Subtyping Built-in Types).
|
||||
on the way to implementing PEP 253 (Subtyping Built-in Types).
|
||||
|
||||
References
|
||||
|
||||
|
|
12
pep-0253.txt
12
pep-0253.txt
|
@ -60,9 +60,9 @@ Introduction
|
|||
- a class statement can contain a slots declaration, specifying
|
||||
the specific names of the instance variables supported
|
||||
|
||||
This PEP builds on pep-0252, which adds standard introspection to
|
||||
This PEP builds on PEP 252, which adds standard introspection to
|
||||
types; e.g., when the type object defines the tp_hash slot, the
|
||||
type object has a __hash__ method. pep-0252 also adds a
|
||||
type object has a __hash__ method. PEP 252 also adds a
|
||||
dictionary to type objects which contains all methods. At the
|
||||
Python level, this dictionary is read-only for built-in types; at
|
||||
the C level, it is accessible directly (but it should not be
|
||||
|
@ -78,10 +78,10 @@ Introduction
|
|||
release.)
|
||||
|
||||
In current Python, a distinction is made between types and
|
||||
classes. This PEP together with pep-0254 will remove that
|
||||
classes. This PEP together with PEP 254 will remove that
|
||||
distinction. However, for backwards compatibility there will
|
||||
probably remain a bit of a distinction for years to come, and
|
||||
without pep-0254, the distinction is still large: types ultimately
|
||||
without PEP 254, the distinction is still large: types ultimately
|
||||
have a built-in type as a base class, while classes ultimately
|
||||
derive from a user-defined class. Therefore, in the rest of this
|
||||
PEP, I will use the word type whenever I can -- including base
|
||||
|
@ -499,7 +499,7 @@ Subtyping in Python
|
|||
Assume B is a type object. Since type objects are objects, and
|
||||
every object has a type, B has a type. B's type is accessible via
|
||||
type(B) or B.__class__ (the latter notation is new for types; it
|
||||
is introduced in pep-0252). Let's say B's type is M (for
|
||||
is introduced in PEP 252). Let's say B's type is M (for
|
||||
Metatype). The class statement will create a new type, C. Since
|
||||
C will be a type object just like B, we view the creation of C as
|
||||
an instantiation of the metatype, M. The information that needs
|
||||
|
@ -599,7 +599,7 @@ Implementation
|
|||
here, see the file Lib/test/test_descr.py and the extension module
|
||||
Modules/spam.c.
|
||||
|
||||
Note: the code in this branch is for pep-0252, pep-0253, and
|
||||
Note: the code in this branch is for PEP 252, PEP 253, and
|
||||
pep-254.
|
||||
|
||||
|
||||
|
|
Loading…
Reference in New Issue