Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix pylint warnings inconsistent-return-statements #1408

Closed
wants to merge 1 commit into from

Conversation

tiran
Copy link
Member

@tiran tiran commented Dec 15, 2017

Add consistent return to all functions and methods that are covered by
tox -e pylint[23]. I haven't checked if return None is always a good
idea or if we should rather raise an error.

See: https://pagure.io/freeipa/issue/7326
Signed-off-by: Christian Heimes cheimes@redhat.com

@tiran tiran added the prioritized Pull Request has higher priority for PR-CI label Dec 15, 2017
@tiran tiran force-pushed the inconsistent-return-statements branch 2 times, most recently from 6fbe9e2 to 491adfa Compare December 15, 2017 16:51
Add consistent return to all functions and methods that are covered by
tox -e pylint[23]. I haven't checked if return None is always a good
idea or if we should rather raise an error.

See: https://pagure.io/freeipa/issue/7326
Signed-off-by: Christian Heimes <cheimes@redhat.com>
@tiran tiran force-pushed the inconsistent-return-statements branch from 491adfa to b40ec0c Compare December 15, 2017 17:19
@@ -77,3 +77,4 @@ def output_for_cli(self, textui, result, ldapuri, **options):
ldapuri)
return 1
textui.print_plain(unicode(self.pwd_migration_msg))
return None
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cli class expects that output_for_cli returns either error code or something that evaluates into a False. In the latter case we get the result silenced (cli.run() returns 0). Probably better to change return None to return 0 for consistency.

@@ -118,6 +118,8 @@ def encrypt(data, symmetric_key=None, public_key=None):
label=None
)
)
else:
return None
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

encrypt() cannot return None because we call base64.b64encode() on the result unconditionally.

>>> import base64
>>> base64.b64encode(None)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python3.6/base64.py", line 58, in b64encode
    encoded = binascii.b2a_base64(s, newline=False)
TypeError: a bytes-like object is required, not 'NoneType'
>>> 

I think for both encrypt() and decrypt() we can return b'' or similar.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, returning b'' is wrong and will hide bugs.

We have returned None in the past. This change just makes it obvious and explicit.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

then I'd suggest to raise an error here. Since both encode and decode cannot function without symmetric or public/private keys, raising an exception is better than failing in base64.

@@ -150,6 +152,8 @@ def decrypt(data, symmetric_key=None, private_key=None):
except ValueError:
raise errors.AuthenticationError(
message=_('Invalid credentials'))
else:
return None
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here -- probably better to return b''

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here. The change just makes return None explicit.

Copy link
Contributor

@abbra abbra left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See inline comments. I think there are at least changes needed in the handling of encrypt/decrypt functions.

@abbra
Copy link
Contributor

abbra commented Dec 18, 2017

@tiran will make a separate PR for the exception raising for non-intended use of decode/encode in vault.py, so this PR is OK..

@abbra abbra added the ack Pull Request approved, can be merged label Dec 18, 2017
@tiran tiran added the pushed Pull Request has already been pushed label Dec 18, 2017
@tiran
Copy link
Member Author

tiran commented Dec 18, 2017

master:

  • 8cb756a Fix pylint warnings inconsistent-return-statements

@tiran tiran closed this Dec 18, 2017
@tiran tiran deleted the inconsistent-return-statements branch December 18, 2017 11:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ack Pull Request approved, can be merged prioritized Pull Request has higher priority for PR-CI pushed Pull Request has already been pushed
Projects
None yet
2 participants