-
-
Notifications
You must be signed in to change notification settings - Fork 33.2k
gh-60712: Include the "object" type in the lists of documented types #103036
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 20 commits
2c09057
9a71e36
d327409
73698a5
1064065
ce4d192
aca2c04
f6c12d8
b1ab4a2
d709946
105f331
119e29b
d8c1995
7762a08
7ffed7c
5ad51b9
71a2d43
2d9f0a0
10adcee
f9961eb
ab5ef40
6681f67
7d68154
3f41130
026e514
7181046
69b710a
55f8c6a
b199746
cf6efa1
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -130,11 +130,13 @@ The standard type hierarchy | |
| pair: extension; module | ||
| pair: C; language | ||
|
|
||
| Below is a list of the types that are built into Python. Extension modules | ||
| (written in C, Java, or other languages, depending on the implementation) can | ||
| define additional types. Future versions of Python may add types to the type | ||
| hierarchy (e.g., rational numbers, efficiently stored arrays of integers, etc.), | ||
| although such additions will often be provided via the standard library instead. | ||
| Below is a list of the types that are built into Python. The fundamental type | ||
| is :class:`object`; all other types, whether built-in or not, are derived | ||
| from it. Extension modules (written in C, Java, or other languages, | ||
| depending on the implementation) can define additional types. Future versions | ||
| of Python may add types to the type hierarchy (e.g., rational numbers, | ||
furkanonder marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
| efficiently stored arrays of integers, etc.), although such additions will | ||
| often be provided via the standard library instead. | ||
terryjreedy marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
|
|
||
| .. index:: | ||
| single: attribute | ||
|
|
@@ -1607,10 +1609,11 @@ Basic customization | |
| class). The return value of :meth:`__new__` should be the new object instance | ||
| (usually an instance of *cls*). | ||
|
|
||
| Typical implementations create a new instance of the class by invoking the | ||
| Typical custom implementations create a new instance of the class by invoking the | ||
furkanonder marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
| superclass's :meth:`__new__` method using ``super().__new__(cls[, ...])`` | ||
| with appropriate arguments and then modifying the newly created instance | ||
| as necessary before returning it. | ||
| with appropriate arguments and then modify the newly created instance as necessary | ||
furkanonder marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
| before returning it. The base implementation in :class:`object` should only be | ||
| passed the *cls* argument, and returns an uninitialized instance of that class. | ||
|
|
||
| If :meth:`__new__` is invoked during object construction and it returns an | ||
| instance of *cls*, then the new instance’s :meth:`__init__` method | ||
|
|
@@ -1632,9 +1635,14 @@ Basic customization | |
| Called after the instance has been created (by :meth:`__new__`), but before | ||
| it is returned to the caller. The arguments are those passed to the | ||
| class constructor expression. If a base class has an :meth:`__init__` | ||
| method, the derived class's :meth:`__init__` method, if any, must explicitly | ||
| method, the derived class's :meth:`__init__` method, if any, may need to | ||
furkanonder marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
| call it to ensure proper initialization of the base class part of the | ||
| instance; for example: ``super().__init__([args...])``. | ||
| Any :meth:`__init__` method that is overridden is not implicitly called. | ||
furkanonder marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
|
|
||
| A base implementation in :class:`object` is provided, but it does not | ||
| need to be called. If it is only passed the *self* argument, it has | ||
| no effect. | ||
|
|
||
| Because :meth:`__new__` and :meth:`__init__` work together in constructing | ||
| objects (:meth:`__new__` to create it, and :meth:`__init__` to customize it), | ||
|
|
@@ -1653,7 +1661,8 @@ Basic customization | |
| finalizer or (improperly) a destructor. If a base class has a | ||
| :meth:`__del__` method, the derived class's :meth:`__del__` method, | ||
| if any, must explicitly call it to ensure proper deletion of the base | ||
| class part of the instance. | ||
| class part of the instance. The :class:`object` class itself does not have a | ||
furkanonder marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
| :meth:`__del__` method. | ||
|
|
||
| It is possible (though not recommended!) for the :meth:`__del__` method | ||
| to postpone destruction of the instance by creating a new reference to | ||
|
|
@@ -1723,7 +1732,8 @@ Basic customization | |
| "informal" string representation of instances of that class is required. | ||
|
|
||
| This is typically used for debugging, so it is important that the representation | ||
| is information-rich and unambiguous. | ||
| is information-rich and unambiguous. A default implementation is provided by the | ||
| :class:`object` class itself. | ||
|
|
||
| .. index:: | ||
| single: string; __str__() (object method) | ||
|
|
@@ -1733,10 +1743,10 @@ Basic customization | |
|
|
||
| .. method:: object.__str__(self) | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I thought we had a doc bug years ago where we came up with a convention to differentiate I guess we didn’t… |
||
|
|
||
| Called by :func:`str(object) <str>` and the built-in functions | ||
| :func:`format` and :func:`print` to compute the "informal" or nicely | ||
| Called by :func:`str(object) <str>`, the default :meth:`__format__` implementation, | ||
merwok marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| and the built-in function :func:`print`, to compute the "informal" or nicely | ||
| printable string representation of an object. The return value must be a | ||
| :ref:`string <textseq>` object. | ||
| :class:`str` object. | ||
furkanonder marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
|
|
||
| This method differs from :meth:`object.__repr__` in that there is no | ||
| expectation that :meth:`__str__` return a valid Python expression: a more | ||
|
|
@@ -1753,7 +1763,8 @@ Basic customization | |
| .. index:: pair: built-in function; bytes | ||
|
|
||
| Called by :ref:`bytes <func-bytes>` to compute a byte-string representation | ||
| of an object. This should return a :class:`bytes` object. | ||
| of an object. This should return a :class:`bytes` object. The :class:`object` | ||
| class itself does not provide this method. | ||
|
|
||
| .. index:: | ||
| single: string; __format__() (object method) | ||
|
|
@@ -1777,6 +1788,9 @@ Basic customization | |
|
|
||
| The return value must be a string object. | ||
|
|
||
| The default implementation by the :class:`object` class should be given | ||
| an empty *format_spec* string. It delegates to :meth:`__str__`. | ||
|
|
||
| .. versionchanged:: 3.4 | ||
| The __format__ method of ``object`` itself raises a :exc:`TypeError` | ||
| if passed any non-empty string. | ||
|
|
@@ -1819,6 +1833,12 @@ Basic customization | |
| ``(x<y or x==y)`` does not imply ``x<=y``. To automatically generate ordering | ||
| operations from a single root operation, see :func:`functools.total_ordering`. | ||
|
|
||
| By default, the :class:`object` class provides implementations consistent | ||
| with :ref:`expressions-value-comparisons`: equality compares according to | ||
| object identity, and order comparisons raise :exc:`TypeError`. Each default | ||
| method may generate these results directly, but may also return | ||
| :data:`NotImplemented`. | ||
|
|
||
| See the paragraph on :meth:`__hash__` for | ||
| some important notes on creating :term:`hashable` objects which support | ||
| custom comparison operations and are usable as dictionary keys. | ||
|
|
@@ -1873,10 +1893,10 @@ Basic customization | |
| immutable (if the object's hash value changes, it will be in the wrong hash | ||
| bucket). | ||
|
|
||
| User-defined classes have :meth:`__eq__` and :meth:`__hash__` methods | ||
| by default; with them, all objects compare unequal (except with themselves) | ||
| and ``x.__hash__()`` returns an appropriate value such that ``x == y`` | ||
| implies both that ``x is y`` and ``hash(x) == hash(y)``. | ||
| User-defined classes (and the :class:`object` class itself) have :meth:`__eq__` | ||
| and :meth:`__hash__` methods by default; with them, all objects compare | ||
furkanonder marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
| unequal (except with themselves) and ``x.__hash__()`` returns an appropriate | ||
| value such that ``x == y`` implies both that ``x is y`` and ``hash(x) == hash(y)``. | ||
|
|
||
| A class that overrides :meth:`__eq__` and does not define :meth:`__hash__` | ||
| will have its :meth:`__hash__` implicitly set to ``None``. When the | ||
|
|
@@ -1926,8 +1946,8 @@ Basic customization | |
| ``bool()``; should return ``False`` or ``True``. When this method is not | ||
| defined, :meth:`~object.__len__` is called, if it is defined, and the object is | ||
| considered true if its result is nonzero. If a class defines neither | ||
| :meth:`!__len__` nor :meth:`!__bool__`, all its instances are considered | ||
| true. | ||
| :meth:`!__len__` nor :meth:`!__bool__` (which is true of the :class:`object` | ||
| class itself), all its instances are considered true. | ||
|
|
||
|
|
||
| .. _attribute-access: | ||
|
|
@@ -1949,6 +1969,7 @@ access (use of, assignment to, or deletion of ``x.name``) for class instances. | |
| for ``self``; or :meth:`__get__` of a *name* property raises | ||
| :exc:`AttributeError`). This method should either return the (computed) | ||
| attribute value or raise an :exc:`AttributeError` exception. | ||
| The :class:`object` class itself does not provide this method. | ||
|
|
||
| Note that if the attribute is found through the normal mechanism, | ||
| :meth:`__getattr__` is not called. (This is an intentional asymmetry between | ||
|
|
@@ -2018,7 +2039,9 @@ access (use of, assignment to, or deletion of ``x.name``) for class instances. | |
| .. method:: object.__dir__(self) | ||
|
|
||
| Called when :func:`dir` is called on the object. An iterable must be | ||
| returned. :func:`dir` converts the returned iterable to a list and sorts it. | ||
| returned. The :func:`dir` function converts the returned iterable to a list | ||
| and sorts it. The :class:`object` class itself provides an implementation | ||
furkanonder marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
| consistent with the :func:`dir` behaviour for arbitrary objects. | ||
|
|
||
|
|
||
| Customizing module attribute access | ||
|
|
@@ -2087,8 +2110,8 @@ method (a so-called *descriptor* class) appears in an *owner* class (the | |
| descriptor must be in either the owner's class dictionary or in the class | ||
| dictionary for one of its parents). In the examples below, "the attribute" | ||
| refers to the attribute whose name is the key of the property in the owner | ||
| class' :attr:`~object.__dict__`. | ||
|
|
||
| class' :attr:`~object.__dict__`. The :class:`object` class itself does not | ||
| implement any of these protocols. | ||
|
|
||
| .. method:: object.__get__(self, instance, owner=None) | ||
|
|
||
|
|
@@ -2780,17 +2803,18 @@ Emulating callable objects | |
|
|
||
| Called when the instance is "called" as a function; if this method is defined, | ||
| ``x(arg1, arg2, ...)`` roughly translates to ``type(x).__call__(x, arg1, ...)``. | ||
|
|
||
| The :class:`object` class itself does not provide this method. | ||
furkanonder marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
|
||
| .. _sequence-types: | ||
|
|
||
| Emulating container types | ||
| ------------------------- | ||
|
|
||
| The following methods can be defined to implement container objects. Containers | ||
| usually are :term:`sequences <sequence>` (such as :class:`lists <list>` or | ||
| The following methods can be defined to implement container objects. None of them | ||
| are provided by the :class:`object` class itself. Containers usually are | ||
| :term:`sequences <sequence>` (such as :class:`lists <list>` or | ||
| :class:`tuples <tuple>`) or :term:`mappings <mapping>` (like | ||
| :class:`dictionaries <dict>`), | ||
| :term:`dictionaries <dictionary>`), | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 🤔 Hm… on the line before, we see a general term used (with a link to glossary) and a concrete example in parens (list and tuple links), then we have the general/glossary term mappings and should keep the specific type dict in parens to keep the intent of the text. On the other hand, if the glossary term for dictionaries is a better explanation than the dict type/function doc, and more specific than the term for mappings, the changed link could be an improvement. |
||
| but can represent other containers as well. The first set of methods is used | ||
| either to emulate a sequence or to emulate a mapping; the difference is that for | ||
| a sequence, the allowable keys should be the integers *k* for which ``0 <= k < | ||
|
|
@@ -3150,6 +3174,7 @@ Typical uses of context managers include saving and restoring various kinds of | |
| global state, locking and unlocking resources, closing opened files, etc. | ||
|
|
||
| For more information on context managers, see :ref:`typecontextmanager`. | ||
| The :class:`object` class itself does not provide the context manager methods. | ||
|
|
||
|
|
||
| .. method:: object.__enter__(self) | ||
|
|
@@ -3354,6 +3379,8 @@ are awaitable. | |
| Must return an :term:`iterator`. Should be used to implement | ||
| :term:`awaitable` objects. For instance, :class:`asyncio.Future` implements | ||
| this method to be compatible with the :keyword:`await` expression. | ||
| The :class:`object` class itself is not awaitable and does not provide | ||
| this method. | ||
|
|
||
| .. note:: | ||
|
|
||
|
|
@@ -3439,6 +3466,9 @@ its ``__anext__`` method. | |
|
|
||
| Asynchronous iterators can be used in an :keyword:`async for` statement. | ||
|
|
||
| The :class:`object` class itself does not provide these methods. | ||
|
|
||
|
|
||
| .. method:: object.__aiter__(self) | ||
|
|
||
| Must return an *asynchronous iterator* object. | ||
|
|
@@ -3485,6 +3515,8 @@ suspend execution in its ``__aenter__`` and ``__aexit__`` methods. | |
|
|
||
| Asynchronous context managers can be used in an :keyword:`async with` statement. | ||
|
|
||
| The :class:`object` class itself does not provide these methods. | ||
|
|
||
| .. method:: object.__aenter__(self) | ||
|
|
||
| Semantically similar to :meth:`~object.__enter__`, the only | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,2 @@ | ||
| Include the :class:`object` type in the lists of documented types. | ||
| Change by Furkan Onder and Martin Panter. |
Uh oh!
There was an error while loading. Please reload this page.