Darglint

Latest version: v1.8.1

Safety actively analyzes 629532 Python packages for vulnerabilities to keep your Python projects secure.

Scan your dependencies

Page 3 of 10

1.5.0

Added

- Settings can now be configured from flake8's configuration
file, or from the flake8 command. Thanks to Harrison88 for
the PR!

Fixed

- Handle bare raise statement in multiple exception handlers.
- Handle bare raise statement in catch-all exception handler.

1.4.1

Fixed

- Handle reraising an error from a handler where the caught
error(s) is a tuple.

1.4.0

Changed

- Private arguments (arguments with a leading underscore)
are no longer required. If present, they will still be
subject to other checks. (For example, if the description
is missing, an error will be reported.)

Fixed

- Handled newlines after Google argument types. Newlines
were handled in most other situations (inside of types,
after an untyped item, etc.) but this one slipped through.
- Handle parentheses inside parenthetical google types.
Previously, darglint simply failed to parse those arguments.
Now it will raise a ParameterMalformedError.

1.3.1

Changed

- Updated README to be more explicit about how Darglint
handles types and style.

Fixed

- Qualified exceptions in a raise section were not being
handled correctly by the `FunctionDescription` class.
So, if you had a catch statement like,

def finish_me():
try:
raise requests.exceptions.ProxyError()
except requests.exceptions.ProxyError:
raise

It wouldn't have been handled correctly. That is, if
you documented `requests.exceptions.ProxyError` in the
docstring, darglint would throw an error. This change
resolves the situation, at lest somewhat. It expects
the documented exception and the caught exception to
match exactly.
- Implicitly raised exceptions which are rethrown was
also not handled. So, for example, if you had:

def throwing_up():
"""Throws up.

Raises:
ProxyError: If failed to yarf.

"""
try:
proxy_puke()
except ProxyError:
raise

Darglint would report an error. It no longer reports
an error in this case. See Issue 88 and Issue 68.

1.3.0

Fixed

- A race condition in the integrity checker. I had moved
the function to be an instance variable, rather than a
member of the class, but I had forgotten to do so with
the docstring representation. So, if the next docstring
was fast enough to parse, it could override the previous
docstring. This didn't happen often because parsing
is what takes the longest, and there is a high variability
between the time it takes to parse each docstring.
- Handle newline after exception in raises section. Rather
than failing to parse the raises section, it now reports
an indentation error.

1.2.3

Changed

- Made ordering of error messages more strict. Error messages
are grouped by function, then sorted alphabetically, then
sorted in place by their line numbers within the function
groups.

Fixed

- Handle the else branch of try-except statements when searching
for raise statements during analysis.
- Handle empty type in Google-style arguments (previously raised
an exception, now it's a darglint error with a description.)
- Handle exceptions raised by the Python module, ast.
- Handle a bare raise statement within an exception handler.
For example, if you have

try:
raise SyntaxError('Wrong!')
except SyntaxError:
raise

Then you know that you really have to document a syntax
error.

Page 3 of 10

© 2024 Safety CLI Cybersecurity Inc. All Rights Reserved.