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

PEP8 and coverage increase #16224

Merged
merged 5 commits into from
Mar 13, 2019
Merged

Conversation

oscargus
Copy link
Contributor

References to other Issues or PRs

Brief description of what is fixed or changed

Increase code quality based on PEP8

Increase coverage in sympy.logic.boolalg

Other comments

Release Notes

NO ENTRY

@oscargus oscargus added Code quality Coverage Related to test coverage or codecov.io labels Mar 10, 2019
@sympy-bot
Copy link

Hi, I am the SymPy bot (v142). I'm here to help you write a release notes entry. Please read the guide on how to write release notes.

  • No release notes entry will be added for this pull request.

Note: This comment will be updated with the latest check if you edit the pull request. You need to reload the page to see it.

Click here to see the pull request description that was parsed.

<!-- Your title above should be a short description of what
was changed. Do not include the issue number in the title. -->

#### References to other Issues or PRs
<!-- If this pull request fixes an issue, write "Fixes #NNNN" in that exact
format, e.g. "Fixes #1234". See
https://github.com/blog/1506-closing-issues-via-pull-requests . Please also
write a comment on that issue linking back to this pull request once it is
open. -->


#### Brief description of what is fixed or changed
Increase code quality based on PEP8

Increase coverage in sympy.logic.boolalg

#### Other comments


#### Release Notes

<!-- Write the release notes for this release below. See
https://github.com/sympy/sympy/wiki/Writing-Release-Notes for more information
on how to write release notes. The bot will check your release notes
automatically to see if they are formatted correctly. -->

<!-- BEGIN RELEASE NOTES -->
NO ENTRY
<!-- END RELEASE NOTES -->

@@ -232,7 +232,8 @@ def __cmp__(self, other):
return (a > b) - (a < b)

def __str__(self):
return '%s(%s)' % (self.__class__.__name__, ', '.join(str(a) for a in self.args))
return '%s(%s)' % (self.__class__.__name__,
', '.join(str(a) for a in self.args))
Copy link
Member

Choose a reason for hiding this comment

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

Here (and below) I don't prefer to have these large hanging indents. IMO, it doesn't add that much to legibility (since I still have to read it sequentially) and it creates more lines when there are longer lists of args. That was part of the rationale for filldedent which allows one to not have to worry about where the text is indented to:

                                    ...
                                    filldedent('''
    This is the text of the long message
    that needs to be printed.''')
                                    ...

(Although last I recall, some wanted this indented properly which means you have lots of short lines...but filldedent makes it look fine in the end.)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

In this particular case the line broke the 80 character limit.

I can only agree that it is sometimes an issue when one tries to avoid long lines and the code is having several levels of indentation already.

So your suggestion is to sometimes break the 80 character limit?

I think that in this case both 80+ and the hanging indent are quite OK, but there are clearly those that look worse below...

I didn't see this comment before I pushed the commit below. Will look further into it tomorrow.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I find it a bit hard to know when to format how. Would it be OK to merge this (and #16223) as is and I promise I will not change anything like this in future PRs? (It may happen that I format new code like it, based on the inability to judge so it is easier to follow rules, but no more PRs like this and #16223 where the main purpose is to reformat, following PEP8.)

Copy link
Member

Choose a reason for hiding this comment

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

So your suggestion is to sometimes break the 80 character limit?

No, I mean I don't like the "intelligent" hanging indent. I prefer just

return '%s(%s)' % (self.__class__.__name__,
    ', '.join(str(a) for a in self.args))

Copy link
Member

Choose a reason for hiding this comment

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

And I try to follow using 8 spaces if the next line is going to be indented:

    if (a long
            condition):
        do this

Copy link
Contributor Author

Choose a reason for hiding this comment

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

OK! I was confused since the example was for an 80+ character line. But there are clearly examples of those hanging indents elsewhere.

Copy link
Member

Choose a reason for hiding this comment

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

The 80 character limit is one of the softer rules in PEP 8. Actually it says:

Some teams strongly prefer a longer line length. For code maintained exclusively or primarily by a team that can reach agreement on this issue, it is okay to increase the line length limit up to 99 characters, provided that comments and docstrings are still wrapped at 72 characters.

I personally avoid wrapping long lines in cases where there isn't an obvious place to break the line (this isn't an example of that, as breaking after a comma is usually fine).

I also don't like the "hanging indent" rule either, as it tends to exacerbate the issue by indenting more than necessary, forcing even more line breaks.

The fact that we don't have immediate agreement on these things is why we don't have PEP 8 code quality checks in SymPy (beyond the ones we can agree on like trailing whitespace).

@@ -932,6 +932,7 @@ def test_relational_simplification():
w, x, y, z = symbols('w x y z', real=True)
d, e = symbols('d e', real=False)
assert Or(x >= y, x < y).simplify() == S.true
assert Or(y <= y, x < y).simplify() == S.true
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This should have been y <= x... But there are more things to fix.

@smichr smichr merged commit fd22ec5 into sympy:master Mar 13, 2019
@oscargus oscargus deleted the pep8fixesandtestlogic branch March 13, 2019 08:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Code quality Coverage Related to test coverage or codecov.io
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants