mirror of
https://github.com/python/cpython.git
synced 2025-11-03 03:22:27 +00:00
#2567: remove new-style/old-style class docs.
This commit is contained in:
parent
dc21db36cb
commit
23e8db57e7
6 changed files with 13 additions and 78 deletions
|
|
@ -730,8 +730,7 @@ set.
|
||||||
|
|
||||||
An optional pointer to a function that returns an iterator for the object. Its
|
An optional pointer to a function that returns an iterator for the object. Its
|
||||||
presence normally signals that the instances of this type are iterable (although
|
presence normally signals that the instances of this type are iterable (although
|
||||||
sequences may be iterable without this function, and classic instances always
|
sequences may be iterable without this function).
|
||||||
have this function, even if they don't define an :meth:`__iter__` method).
|
|
||||||
|
|
||||||
This function has the same signature as :cfunc:`PyObject_GetIter`.
|
This function has the same signature as :cfunc:`PyObject_GetIter`.
|
||||||
|
|
||||||
|
|
@ -742,9 +741,7 @@ set.
|
||||||
|
|
||||||
An optional pointer to a function that returns the next item in an iterator, or
|
An optional pointer to a function that returns the next item in an iterator, or
|
||||||
raises :exc:`StopIteration` when the iterator is exhausted. Its presence
|
raises :exc:`StopIteration` when the iterator is exhausted. Its presence
|
||||||
normally signals that the instances of this type are iterators (although classic
|
normally signals that the instances of this type are iterators.
|
||||||
instances always have this function, even if they don't define a
|
|
||||||
:meth:`__next__` method).
|
|
||||||
|
|
||||||
Iterator types should also define the :attr:`tp_iter` function, and that
|
Iterator types should also define the :attr:`tp_iter` function, and that
|
||||||
function should return the iterator instance itself (not a new iterator
|
function should return the iterator instance itself (not a new iterator
|
||||||
|
|
|
||||||
|
|
@ -39,10 +39,6 @@ Glossary
|
||||||
"intermediate language" is said to run on a "virtual machine" that calls
|
"intermediate language" is said to run on a "virtual machine" that calls
|
||||||
the subroutines corresponding to each bytecode.
|
the subroutines corresponding to each bytecode.
|
||||||
|
|
||||||
classic class
|
|
||||||
One of the two flavors of classes in earlier Python versions. Since
|
|
||||||
Python 3.0, there are no classic classes anymore.
|
|
||||||
|
|
||||||
complex number
|
complex number
|
||||||
An extension of the familiar real number system in which all numbers are
|
An extension of the familiar real number system in which all numbers are
|
||||||
expressed as a sum of a real part and an imaginary part. Imaginary
|
expressed as a sum of a real part and an imaginary part. Imaginary
|
||||||
|
|
@ -367,8 +363,6 @@ Glossary
|
||||||
versatile features like :attr:`__slots__`, descriptors, properties,
|
versatile features like :attr:`__slots__`, descriptors, properties,
|
||||||
:meth:`__getattribute__`, class methods, and static methods.
|
:meth:`__getattribute__`, class methods, and static methods.
|
||||||
|
|
||||||
More information can be found in :ref:`newstyle`.
|
|
||||||
|
|
||||||
positional argument
|
positional argument
|
||||||
The arguments assigned to local names inside a function or method,
|
The arguments assigned to local names inside a function or method,
|
||||||
determined by the order in which they were given in the call. ``*`` is
|
determined by the order in which they were given in the call. ``*`` is
|
||||||
|
|
|
||||||
|
|
@ -26,11 +26,9 @@ instances.
|
||||||
|
|
||||||
.. function:: pickle(type, function[, constructor])
|
.. function:: pickle(type, function[, constructor])
|
||||||
|
|
||||||
Declares that *function* should be used as a "reduction" function for objects of
|
Declares that *function* should be used as a "reduction" function for objects
|
||||||
type *type*; *type* must not be a "classic" class object. (Classic classes are
|
of type *type*. *function* should return either a string or a tuple
|
||||||
handled differently; see the documentation for the :mod:`pickle` module for
|
containing two or three elements.
|
||||||
details.) *function* should return either a string or a tuple containing two or
|
|
||||||
three elements.
|
|
||||||
|
|
||||||
The optional *constructor* parameter, if provided, is a callable object which
|
The optional *constructor* parameter, if provided, is a callable object which
|
||||||
can be used to reconstruct the object when called with the tuple of arguments
|
can be used to reconstruct the object when called with the tuple of arguments
|
||||||
|
|
|
||||||
|
|
@ -403,6 +403,7 @@ Pickling and unpickling normal class instances
|
||||||
single: __init__() (instance constructor)
|
single: __init__() (instance constructor)
|
||||||
|
|
||||||
.. XXX is __getinitargs__ only used with old-style classes?
|
.. XXX is __getinitargs__ only used with old-style classes?
|
||||||
|
.. XXX update w.r.t Py3k's classes
|
||||||
|
|
||||||
When a pickled class instance is unpickled, its :meth:`__init__` method is
|
When a pickled class instance is unpickled, its :meth:`__init__` method is
|
||||||
normally *not* invoked. If it is desirable that the :meth:`__init__` method be
|
normally *not* invoked. If it is desirable that the :meth:`__init__` method be
|
||||||
|
|
@ -447,8 +448,8 @@ can do what they want. [#]_
|
||||||
|
|
||||||
.. warning::
|
.. warning::
|
||||||
|
|
||||||
For :term:`new-style class`\es, if :meth:`__getstate__` returns a false
|
If :meth:`__getstate__` returns a false value, the :meth:`__setstate__`
|
||||||
value, the :meth:`__setstate__` method will not be called.
|
method will not be called.
|
||||||
|
|
||||||
|
|
||||||
Pickling and unpickling extension types
|
Pickling and unpickling extension types
|
||||||
|
|
|
||||||
|
|
@ -577,9 +577,8 @@ can be set in a method with ``self.name = value``. Both class and instance
|
||||||
variables are accessible through the notation "``self.name``", and an instance
|
variables are accessible through the notation "``self.name``", and an instance
|
||||||
variable hides a class variable with the same name when accessed in this way.
|
variable hides a class variable with the same name when accessed in this way.
|
||||||
Class variables can be used as defaults for instance variables, but using
|
Class variables can be used as defaults for instance variables, but using
|
||||||
mutable values there can lead to unexpected results. For :term:`new-style
|
mutable values there can lead to unexpected results. Descriptors can be used
|
||||||
class`\es, descriptors can be used to create instance variables with different
|
to create instance variables with different implementation details.
|
||||||
implementation details.
|
|
||||||
|
|
||||||
.. XXX add link to descriptor docs above
|
.. XXX add link to descriptor docs above
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -980,45 +980,6 @@ Internal types
|
||||||
by the built-in :func:`classmethod` constructor.
|
by the built-in :func:`classmethod` constructor.
|
||||||
|
|
||||||
|
|
||||||
.. _newstyle:
|
|
||||||
|
|
||||||
New-style and classic classes
|
|
||||||
=============================
|
|
||||||
|
|
||||||
Classes and instances come in two flavors: old-style or classic, and new-style.
|
|
||||||
|
|
||||||
Up to Python 2.1, old-style classes were the only flavour available to the user.
|
|
||||||
The concept of (old-style) class is unrelated to the concept of type: if *x* is
|
|
||||||
an instance of an old-style class, then ``x.__class__`` designates the class of
|
|
||||||
*x*, but ``type(x)`` is always ``<type 'instance'>``. This reflects the fact
|
|
||||||
that all old-style instances, independently of their class, are implemented with
|
|
||||||
a single built-in type, called ``instance``.
|
|
||||||
|
|
||||||
New-style classes were introduced in Python 2.2 to unify classes and types. A
|
|
||||||
new-style class is neither more nor less than a user-defined type. If *x* is an
|
|
||||||
instance of a new-style class, then ``type(x)`` is the same as ``x.__class__``.
|
|
||||||
|
|
||||||
The major motivation for introducing new-style classes is to provide a unified
|
|
||||||
object model with a full meta-model. It also has a number of immediate
|
|
||||||
benefits, like the ability to subclass most built-in types, or the introduction
|
|
||||||
of "descriptors", which enable computed properties.
|
|
||||||
|
|
||||||
For compatibility reasons, classes are still old-style by default. New-style
|
|
||||||
classes are created by specifying another new-style class (i.e. a type) as a
|
|
||||||
parent class, or the "top-level type" :class:`object` if no other parent is
|
|
||||||
needed. The behaviour of new-style classes differs from that of old-style
|
|
||||||
classes in a number of important details in addition to what :func:`type`
|
|
||||||
returns. Some of these changes are fundamental to the new object model, like
|
|
||||||
the way special methods are invoked. Others are "fixes" that could not be
|
|
||||||
implemented before for compatibility concerns, like the method resolution order
|
|
||||||
in case of multiple inheritance.
|
|
||||||
|
|
||||||
This manual is not up-to-date with respect to new-style classes. For now,
|
|
||||||
please see http://www.python.org/doc/newstyle/ for more information.
|
|
||||||
|
|
||||||
.. XXX remove old style classes from docs
|
|
||||||
|
|
||||||
|
|
||||||
.. _specialnames:
|
.. _specialnames:
|
||||||
|
|
||||||
Special method names
|
Special method names
|
||||||
|
|
@ -1418,9 +1379,7 @@ continuing through the base classes of ``type(a)`` excluding metaclasses.
|
||||||
However, if the looked-up value is an object defining one of the descriptor
|
However, if the looked-up value is an object defining one of the descriptor
|
||||||
methods, then Python may override the default behavior and invoke the descriptor
|
methods, then Python may override the default behavior and invoke the descriptor
|
||||||
method instead. Where this occurs in the precedence chain depends on which
|
method instead. Where this occurs in the precedence chain depends on which
|
||||||
descriptor methods were defined and how they were called. Note that descriptors
|
descriptor methods were defined and how they were called.
|
||||||
are only invoked for new style objects or classes (ones that subclass
|
|
||||||
:class:`object()` or :class:`type()`).
|
|
||||||
|
|
||||||
The starting point for descriptor invocation is a binding, ``a.x``. How the
|
The starting point for descriptor invocation is a binding, ``a.x``. How the
|
||||||
arguments are assembled depends on ``a``:
|
arguments are assembled depends on ``a``:
|
||||||
|
|
@ -1477,7 +1436,7 @@ saved because *__dict__* is not created for each instance.
|
||||||
.. data:: object.__slots__
|
.. data:: object.__slots__
|
||||||
|
|
||||||
This class variable can be assigned a string, iterable, or sequence of
|
This class variable can be assigned a string, iterable, or sequence of
|
||||||
strings with variable names used by instances. If defined in a new-style
|
strings with variable names used by instances. If defined in a
|
||||||
class, *__slots__* reserves space for the declared variables and prevents the
|
class, *__slots__* reserves space for the declared variables and prevents the
|
||||||
automatic creation of *__dict__* and *__weakref__* for each instance.
|
automatic creation of *__dict__* and *__weakref__* for each instance.
|
||||||
|
|
||||||
|
|
@ -1801,7 +1760,7 @@ left undefined.
|
||||||
``-``, ``*``, ``/``, ``%``, :func:`divmod`, :func:`pow`, ``**``, ``<<``, ``>>``,
|
``-``, ``*``, ``/``, ``%``, :func:`divmod`, :func:`pow`, ``**``, ``<<``, ``>>``,
|
||||||
``&``, ``^``, ``|``) with reflected (swapped) operands. These functions are
|
``&``, ``^``, ``|``) with reflected (swapped) operands. These functions are
|
||||||
only called if the left operand does not support the corresponding operation and
|
only called if the left operand does not support the corresponding operation and
|
||||||
the operands are of different types. [#]_ For instance, to evaluate the
|
the operands are of different types. [#]_ For instance, to evaluate the
|
||||||
expression *x*``-``*y*, where *y* is an instance of a class that has an
|
expression *x*``-``*y*, where *y* is an instance of a class that has an
|
||||||
:meth:`__rsub__` method, ``y.__rsub__(x)`` is called if ``x.__sub__(y)`` returns
|
:meth:`__rsub__` method, ``y.__rsub__(x)`` is called if ``x.__sub__(y)`` returns
|
||||||
*NotImplemented*.
|
*NotImplemented*.
|
||||||
|
|
@ -1927,18 +1886,6 @@ For more information on context managers, see :ref:`typecontextmanager`.
|
||||||
|
|
||||||
.. rubric:: Footnotes
|
.. rubric:: Footnotes
|
||||||
|
|
||||||
.. [#] Since Python 2.2, a gradual merging of types and classes has been started that
|
|
||||||
makes this and a few other assertions made in this manual not 100% accurate and
|
|
||||||
complete: for example, it *is* now possible in some cases to change an object's
|
|
||||||
type, under certain controlled conditions. Until this manual undergoes
|
|
||||||
extensive revision, it must now be taken as authoritative only regarding
|
|
||||||
"classic classes", that are still the default, for compatibility purposes, in
|
|
||||||
Python 2.2 and 2.3. For more information, see
|
|
||||||
http://www.python.org/doc/newstyle/.
|
|
||||||
|
|
||||||
.. [#] This, and other statements, are only roughly true for instances of new-style
|
|
||||||
classes.
|
|
||||||
|
|
||||||
.. [#] A descriptor can define any combination of :meth:`__get__`,
|
.. [#] A descriptor can define any combination of :meth:`__get__`,
|
||||||
:meth:`__set__` and :meth:`__delete__`. If it does not define :meth:`__get__`,
|
:meth:`__set__` and :meth:`__delete__`. If it does not define :meth:`__get__`,
|
||||||
then accessing the attribute even on an instance will return the descriptor
|
then accessing the attribute even on an instance will return the descriptor
|
||||||
|
|
@ -1949,4 +1896,3 @@ For more information on context managers, see :ref:`typecontextmanager`.
|
||||||
.. [#] For operands of the same type, it is assumed that if the non-reflected method
|
.. [#] For operands of the same type, it is assumed that if the non-reflected method
|
||||||
(such as :meth:`__add__`) fails the operation is not supported, which is why the
|
(such as :meth:`__add__`) fails the operation is not supported, which is why the
|
||||||
reflected method is not called.
|
reflected method is not called.
|
||||||
|
|
||||||
|
|
|
||||||
Loading…
Add table
Add a link
Reference in a new issue