[docs] include the "object" type in the lists of documented types (issue 16508)

ezio.melotti at gmail.com ezio.melotti at gmail.com
Fri Jan 1 19:05:54 EST 2016


http://bugs.python.org/review/16508/diff/15301/Doc/library/functions.rst
File Doc/library/functions.rst (right):

http://bugs.python.org/review/16508/diff/15301/Doc/library/functions.rst#newcode855
Doc/library/functions.rst:855: The constructor does not accept any
arguments.
What about:
`object` is a type used as base class for all other classes.
When called, it accepts no arguments and returns a new unique and
featureless object.

http://bugs.python.org/review/16508/diff/15301/Doc/library/functions.rst#newcode861
Doc/library/functions.rst:861: the :class:`object` class.
I think this note might be removed, and replaced with a sentence that
says that object already defines some methods/attributes (but not
others) and link to the list of methods.
There it can be explained in more details what are the
methods/attributes, and that __dict__ is not one of them.

http://bugs.python.org/review/16508/diff/15301/Doc/library/stdtypes.rst
File Doc/library/stdtypes.rst (right):

http://bugs.python.org/review/16508/diff/15301/Doc/library/stdtypes.rst#newcode4326
Doc/library/stdtypes.rst:4326: instances of :class:`object`, the
universal type. Most of these support
I'm not sure I would use universal here.

http://bugs.python.org/review/16508/diff/15301/Doc/reference/datamodel.rst
File Doc/reference/datamodel.rst (right):

http://bugs.python.org/review/16508/diff/15301/Doc/reference/datamodel.rst#newcode131
Doc/reference/datamodel.rst:131: whether built-in or not, are derived
from it.  Extension modules
You already called it "ultimate", "universal", and now "fundamental".  I
don't like any of those terms.

You can simply say: All types, built-in or not, are derived from
:class:`object`.

http://bugs.python.org/review/16508/diff/15301/Doc/reference/datamodel.rst#newcode1146
Doc/reference/datamodel.rst:1146: :meth:`__del__` method.  Note that it
is possible
I wonder if it's better to split the actual object methods, with the
ones that users must define themselves.

The former can use :meth:`object.__*__` and describe the behavior of the
default implementation, whereas the latter can use :meth:`cls.__*__`,
describe what the method should do, and possibly link to the default
implementation.
This might also save you from repeating "object doesn't implement this
method" several times.

http://bugs.python.org/review/16508/diff/15301/Lib/test/test_class.py
File Lib/test/test_class.py (right):

http://bugs.python.org/review/16508/diff/15301/Lib/test/test_class.py#newcode541
Lib/test/test_class.py:541: self.assertFalse(hasattr(c, "__call__"))
Maybe add a test for __dict__ too.

http://bugs.python.org/review/16508/


More information about the docs mailing list