This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: allow constructors to be documented separately from class
Type: enhancement Stage:
Components: Documentation Versions:
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: docs@python Nosy List: Arfrever, chris.jerdonek, docs@python, eric.araujo, ezio.melotti, georg.brandl, ncoghlan, terry.reedy
Priority: normal Keywords:

Created on 2012-11-28 09:03 by chris.jerdonek, last changed 2022-04-11 14:57 by admin.

Messages (6)
msg176524 - (view) Author: Chris Jerdonek (chris.jerdonek) * (Python committer) Date: 2012-11-28 09:03
This issue is to settle on and provide a way to document the constructor of a class separately from the overall summary/description of a class.

This is something that Ezio, Nick, and I discussed briefly on IRC a few hours ago.  We all see the value in it.

Currently, Sphinx's "class" directive is used in many places to document the constructor of a class.  One drawback of this approach is that linking to the class using the :class: role links to the constructor as opposed to the class summary.  As a result, in many cases the class description needs to be added before the class directive, and a second link needs to be created and used for the overall description.

One way to address this would be to create a new "constructor" directive similar to directives like method, classmethod, and staticmethod.  The constructor documentation could then be hyperlinked to using a new :constructor: role (or perhaps :ctor: to go with the pattern of 4-letter roles).  The class summary could then go immediately after the class directive, with the constructor directive following, as follows:

.. class:: Foo

   Description of Foo.

   .. constructor:: Foo(bar=1)
   
      Return a Foo.

This could render as--

class **Foo**

   Description of Foo.
   
   *constructor* **Foo**(bar=1)

      Return a Foo.

It is possible that something similar could be achieved by abusing the method directive for constructors and linking to them using :meth:`~Foo.Foo`, but that wouldn't be ideal in a few respects.

Nick also raised a related issue for base classes, etc.  I will let him speak to that issue, which might be best as part of another new issue.
msg176567 - (view) Author: Ezio Melotti (ezio.melotti) * (Python committer) Date: 2012-11-28 18:44
I was wondering if this should be called initializer instead of constructor.  Another idea is to keep using the "method" directive and use :initializer: to differentiate it from the others.  This might be easier to implement, but OTOH is not consistent with the staticmethod and classmethod directives though.
msg176619 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2012-11-29 03:42
I’m interested in an explanation of the value of doing this.

In the threading docs for example, the classes (i.e. initializers) are documented in one section, with awkward links to “Thread objects”, “Lock objects”, etc.  This felt much more cumbersome to me than more modern class/attribute/method combos.  Isn’t it the simplest thing to document one class, usage, constructors and all attributes, in one place?

On the other hand, I don’t have the view of an outsider anymore, so I can’t say what makes sense / reads better for the doc’s audience (as opposed to doc editors).
msg176621 - (view) Author: Ezio Melotti (ezio.melotti) * (Python committer) Date: 2012-11-29 03:53
This came up while documenting the str type in datamodel.rst (IIRC), and linking to it from functions.rst.

On one hand you want to say what the str type is, on the other hand you want to document the constructor and explain how can you use str() to obtain str objects.
Putting both under the constructor doesn't work too well, especially when there's a lot of text.  Putting the str type description in a plain paragraph before the "class" directive doesn't work too well either, because :class:`str` will link to the constructor documentation.

The idea is to keep the two separate but still provide an easy way to link to the class without missing the general description.
msg176623 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2012-11-29 04:07
For all the built-in types, I see the value now.

Thinking aloud: Separating the namespaces used by the str and func roles would probably require too many changes in Sphinx.

The current way is to use the function directive to document the class/constructor usage in one place, and use ref to link to the section describing the class.  You can also have the cool class/method combo if you configure the class directive with the noindex option.  Is that not good enough?
msg176625 - (view) Author: Ezio Melotti (ezio.melotti) * (Python committer) Date: 2012-11-29 04:18
> For all the built-in types, I see the value now.

The same applies for non built-in types too though (e.g. http://docs.python.org/3.4/library/collections.html).  The only difference is that the built-in ones have entries in functions.rst and use more links.

> Is that not good enough?

Not really, and creating additional links and suppressing others with :noindex: feels wrong.  The idea is that :class:`str` should just work and link to the right place.
History
Date User Action Args
2022-04-11 14:57:38adminsetgithub: 60772
2012-12-03 08:10:13Arfreversetnosy: + Arfrever
2012-11-30 21:38:30terry.reedysetnosy: + terry.reedy
2012-11-29 04:18:10ezio.melottisetmessages: + msg176625
2012-11-29 04:07:36eric.araujosetmessages: + msg176623
2012-11-29 03:53:24ezio.melottisetmessages: + msg176621
2012-11-29 03:42:14eric.araujosetmessages: + msg176619
2012-11-29 03:28:13ezio.melottisetnosy: + eric.araujo
2012-11-28 18:49:04ezio.melottisetnosy: + georg.brandl
2012-11-28 18:44:49ezio.melottisetmessages: + msg176567
2012-11-28 09:03:32chris.jerdonekcreate