[Python-checkins] CVS: python/nondist/peps pep-0252.txt,1.13,1.14 pep-0253.txt,1.13,1.14
A.M. Kuchling
akuchling@users.sourceforge.net
Wed, 18 Jul 2001 06:45:00 -0700
Update of /cvsroot/python/python/nondist/peps
In directory usw-pr-cvs1:/tmp/cvs-serv2747
Modified Files:
pep-0252.txt pep-0253.txt
Log Message:
Fix some typos (without, I trust, changing any of the semantics)
Index: pep-0252.txt
===================================================================
RCS file: /cvsroot/python/python/nondist/peps/pep-0252.txt,v
retrieving revision 1.13
retrieving revision 1.14
diff -C2 -r1.13 -r1.14
*** pep-0252.txt 2001/07/13 21:50:48 1.13
--- pep-0252.txt 2001/07/18 13:44:57 1.14
***************
*** 63,67 ****
containing methods and class variables defined by the class
itself, and a __bases__ attribute, which is a tuple of base
! classes that must be inspected recursively. Some assumption here
are:
--- 63,67 ----
containing methods and class variables defined by the class
itself, and a __bases__ attribute, which is a tuple of base
! classes that must be inspected recursively. Some assumptions here
are:
***************
*** 88,93 ****
names supported by the object.
! The type API is sometimes combined by a __dict__ that works the
! same was as for instances (for example for function objects in
Python 2.1, f.__dict__ contains f's dynamic attributes, while
f.__members__ lists the names of f's statically defined
--- 88,93 ----
names supported by the object.
! The type API is sometimes combined with a __dict__ that works the
! same as for instances (for example for function objects in
Python 2.1, f.__dict__ contains f's dynamic attributes, while
f.__members__ lists the names of f's statically defined
***************
*** 96,100 ****
Some caution must be exercised: some objects don't list theire
"intrinsic" attributes (like __dict__ and __doc__) in __members__,
! while others do; sometimes attribute names that occur both in
__members__ or __methods__ and as keys in __dict__, in which case
it's anybody's guess whether the value found in __dict__ is used
--- 96,100 ----
Some caution must be exercised: some objects don't list theire
"intrinsic" attributes (like __dict__ and __doc__) in __members__,
! while others do; sometimes attribute names occur both in
__members__ or __methods__ and as keys in __dict__, in which case
it's anybody's guess whether the value found in __dict__ is used
***************
*** 221,225 ****
should be a sequence (not necessarily a tuple) of other
meta-objects, the bases. An absent __bases__ is equivalent to
! an empty sequece 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
--- 221,225 ----
should be a sequence (not necessarily a tuple) of other
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
***************
*** 247,251 ****
has precedence.
! Rationale: we can't have a simples rule like "static overrides
dynamic" or "dynamic overrides static", because some static
attributes indeed override dynamic attributes; for example, a
--- 247,251 ----
has precedence.
! Rationale: we can't have a simple rule like "static overrides
dynamic" or "dynamic overrides static", because some static
attributes indeed override dynamic attributes; for example, a
Index: pep-0253.txt
===================================================================
RCS file: /cvsroot/python/python/nondist/peps/pep-0253.txt,v
retrieving revision 1.13
retrieving revision 1.14
diff -C2 -r1.13 -r1.14
*** pep-0253.txt 2001/07/13 19:48:07 1.13
--- pep-0253.txt 2001/07/18 13:44:57 1.14
***************
*** 28,32 ****
the system may provide a default behavior in that case or raise an
exception when the behavior is invoked. Some collections of
! functions pointers that are usually defined together are obtained
indirectly via a pointer to an additional structure containing
more function pointers.
--- 28,32 ----
the system may provide a default behavior in that case or raise an
exception when the behavior is invoked. Some collections of
! function pointers that are usually defined together are obtained
indirectly via a pointer to an additional structure containing
more function pointers.
***************
*** 50,54 ****
dictionary)
! - the standard coercions functions (int, tuple, str etc.) will
be redefined to be the corresponding type objects, which serve
as their own factory functions
--- 50,54 ----
dictionary)
! - the standard coercion functions (int, tuple, str etc.) will
be redefined to be the corresponding type objects, which serve
as their own factory functions
***************
*** 241,245 ****
they ensure. The tp_new() slot should ensure only the most
essential invariants, without which the C code that implements the
! object's wold break. The tp_init() slot should be used for
overridable user-specific initializations. Take for example the
dictionary type. The implementation has an internal pointer to a
--- 241,245 ----
they ensure. The tp_new() slot should ensure only the most
essential invariants, without which the C code that implements the
! object's would break. The tp_init() slot should be used for
overridable user-specific initializations. Take for example the
dictionary type. The implementation has an internal pointer to a
***************
*** 252,256 ****
Note that for immutable object types, the initialization cannot be
done by the tp_init() slot: this would provide the Python user
! with a way to change the initialiation. Therefore, immutable
objects typically have an empty tp_init() implementation and do
all their initialization in their tp_new() slot.
--- 252,256 ----
Note that for immutable object types, the initialization cannot be
done by the tp_init() slot: this would provide the Python user
! with a way to change the initialization. Therefore, immutable
objects typically have an empty tp_init() implementation and do
all their initialization in their tp_new() slot.
***************
*** 319,323 ****
formula to determine the amount of memory to allocate, and takes
care of GC registration. The only reason not to use this
! implementation would be to allocate objects from different heap
(as is done by some very small frequently used objects like ints
and tuples). PyType_GenericNew() adds very little: it just calls
--- 319,323 ----
formula to determine the amount of memory to allocate, and takes
care of GC registration. The only reason not to use this
! implementation would be to allocate objects from a different heap
(as is done by some very small frequently used objects like ints
and tuples). PyType_GenericNew() adds very little: it just calls
***************
*** 380,384 ****
void tp_free(PyObject *object)
! (In a previous version of this PEP, there was also role reserved
for the tp_clear() slot. This turned out to be a bad idea.)
--- 380,384 ----
void tp_free(PyObject *object)
! (In a previous version of this PEP, there was also a role reserved
for the tp_clear() slot. This turned out to be a bad idea.)
***************
*** 531,535 ****
# etc.
! The body of the class statement is executes in a fresh environment
(basically, a new dictionary used as local namespace), and then C
is created. The following explains how C is created.
--- 531,535 ----
# etc.
! The body of the class statement is executed in a fresh environment
(basically, a new dictionary used as local namespace), and then C
is created. The following explains how C is created.