Fixed
- Made error handling more robust. If darglint is unable to parse, now,
it will display an error message for that function. This error message
is taken from the assert statements in the parser, or is a general
message. This, at least, prevents an ugly stack trace and provides a
model for how to handle style errors in the future.
- Fixed a couple of type errors. Typing is either going to be removed
or moved to a different format to allow for < Python3.6.
- Previously, returns in inner functions would raise errors for missing
returns sections in the docstring, even if (for example), the parent
function yielded values. For example:
- Broken tests were fixed. (The `ast` module does not return functions
in any particular order, but tests were relying on a specific order.)
def walk(root):
"""Walk the tree, yielding active nodes.
Args:
root: The root of the tree.
Yields:
Active nodes.
"""
def skip(node):
return node.inactive
queue = deque()
queue.append(root)
while len(queue) > 0:
curr = queue.pop()
if skip(curr):
continue
yield curr
queue.extend(curr.children)
This function previously would have raised a missing return error
(I201), and would have required a noqa. That is no longer the case.
Changed
- Renamed "darglint.py" to a more appropriate name: "function_description.py".
Added
- `ParserException` is thrown if there is no colon after the type annotation
or argument/exception in the description.
For example, the following function would raise the `ParserException`:
def hello(name):
"""Say hello to the person.
Args:
name: The name of the person to
whom we are saying hello.
"""
print('hello, {}'.format(name))
- Added optional hint to the function `_expect_type` in `darglint/parse.py`.
This will be displayed after the default message. We'll have to add
an option for hints in the configuration, and show or hide them accordingly.
- Added check to ensure that a description exists after an item in the
argument descriptions or exception descriptions (or any multi-section).
At some point, this should probably be optional, but it is currently
raises a `ParserException` (which is too general to really want to
exclude.)