You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Nov 3, 2023. It is now read-only.
I can't seem to find any good examples on the internet concerning meaningful __init__ docstrings. There may be times when there are no parameters, or perhaps documenting the parameters would be helpful.
PEP 257 does say:
Public methods (including the __init__ constructor) should also have docstrings.
but applying this rule seems unnecessary at times.
This is what makes sense to me:
classKlass:
"""Docstring here."""def__init__(self, component):
""" component - The component to model. Can be a name or something else. """self.component=component
But of course, pep257 gives this:
PEP257 Short description should end with a period.
This is what I have ended up doing, but it seems awkward and unnecessary just to ensure pep257 does not complain.
Example:
def__init__(self, component):
"""The constructor. component - The component to model. Can be the name of the model or a path to a file. """self.component=component
I have tried searching online to see how industry treats it, but it seems almost everyone doesn't document the __init__ unless there is a compelling reason to do so. As an example, see the Error class in pep257. :D
classError(object):
"""Error in docstring style. * Stores relevant data about the error, * provides format for printing an error, * provides __lt__ method to sort errors. """# options that define how errors are printedexplain=Falserange=Falsequote=Falsedef__init__(self, filename, source, docstring, context,
explanation, start=None, end=None):
self.filename=filenameself.source=sourceself.docstring=docstringself.context=contextself.explanation=explanation.strip()
So the question is, can/should something be added/changed in pep257 to avoid this? Is this a problem with the specification, the tool, or perhaps neither?
Any insight you guys have would be great.
The text was updated successfully, but these errors were encountered:
Error doesn't have __init__ docstring because Error is not a part of a public interface. This is not explicit right now, but soon pep257 will try to check that in __all__ variable.
In your case I would do:
classBackend:
"""Docstring here."""def__init__(self, component):
"""Backend that is based on a `component`."""self.component=component
So I don't see any need to change pep257 or PEP 257.
I can't seem to find any good examples on the internet concerning meaningful
__init__
docstrings. There may be times when there are no parameters, or perhaps documenting the parameters would be helpful.PEP 257 does say:
but applying this rule seems unnecessary at times.
This is what makes sense to me:
But of course, pep257 gives this:
This is what I have ended up doing, but it seems awkward and unnecessary just to ensure pep257 does not complain.
Example:
I have tried searching online to see how industry treats it, but it seems almost everyone doesn't document the
__init__
unless there is a compelling reason to do so. As an example, see the Error class in pep257. :DSo the question is, can/should something be added/changed in pep257 to avoid this? Is this a problem with the specification, the tool, or perhaps neither?
Any insight you guys have would be great.
The text was updated successfully, but these errors were encountered: