-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
PR: Make the internal console use the same theme as the other widgets #8251
Conversation
Hello @dalthviz! Thanks for updating the PR.
Comment last updated on November 22, 2018 at 19:43 Hours UTC |
@dalthviz, please remove Also, please remove |
Screenshot :-p ? |
@ccordoba12 @goanpeca a preview: Find/Replace:Find in Files:MessageboxInformation:Internal Console: |
…tawesome valid versions
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Essentially two main comments: We should IMO require QDarkStyle 2.6.3, and the hanging indents were all over the place (some 8 spaces, some 16, while PEP 8 specifies 4 except in function def
s (Spyder's automatic indent behavior here is incorrect).
That is not my understanding from https://www.python.org/dev/peps/pep-0008/#indentation and in particular "The 4-space rule is optional for continuation lines." Nevertheless, I usually prefer 4 spaces. |
That is my understanding also. PEP 8 is suggesting, not specifying to use 4 spaces for hanging indents. But, in our wiki (https://github.com/spyder-ide/spyder/wiki/Dev:-Coding-Style#python-style), we clearly state to "Always use four (4) spaces for indentation." So I suggest that we update this section every time a coding style issue arise in one of our PR and stick to it. |
I mis-remembered that it was at the recommendation, not suggestion level but you are clearly correct. My mistaken wording, sorry. Ultimately, the justification for the change was that 4 spaces was what we universally use everywhere else for continuation lines, and therefore we should be consistent.
Great suggestion! For starters I can add what @ccordoba12 decided about not following the "one-line summary" rule for docstrings in the tests. We can also add a "Project Standards" section in the Contributing Guide with a bullet point summary and then links to that wiki page for more information. |
Responding to @dalthviz 's comment above:
PEP 8 is meant to be broken if its clear that doing something different is optimal for a specific case, and it is broken consistently. The problem, however, arises when one's own personal preference is not the same as everybody else's personal preference in a large project like Spyder, leading to both inconsistency (both de-jure, with our coding guidelines, and de-facto, with most if not all of the other new code in Spyder), and being more difficult to understand, never mind apply to one's own code, for anyone else not used to it. Personally, I find it confusing and harder to grasp at a glance myself; that may be because I'm not used to it but that's exactly my point). In fact, even in this PR it isn't done consistently, as several others I pointed out have 4 or 8 spaces. Furthermore, this isn't even really a hanging indent at all, since by the definitions I've seen, a hanging indent is necessarily some fixed number >0 of spaces right of the start of the previous line or the margin, whereas this indent, like that lining up with the parens, is indexed to a particular character in the above. There's no particular name for it, since it doesn't exist at all in PEP 8. Finally, it due to the choice of indent (lining up with the IMO, unless we all agree we like this style, will follow this style in all new code, and will instruct new contributors on this style, we should stick with a consistent 4-space hanging indent (or at least a n-space hanging indent with some consistent number of spaces, not...whatever this is, since its not even really a hanging indent at all). @jnsebgosselin @jitseniesen Your opinions, since we just discussed this below? |
It's not my call, but I can still give my opinion :) I'm in favor of using 4-space hanging indents everywhere. It's clear, easy to follow and ensure consistency throughout the code. |
That's my opinion as well, and it also seems to be what we've been doing for all new and modified code. |
Me too, with the exception of situations like if some_long_function_name(
param1, param2, param3):
do_something()
do_something_else() where a 4-space indent in the second line would be quite confusing IMO. |
Yes, agreed; PEP 8 proposed a few different ways to handle |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dalthviz, I think this can be refactored to simplify it quite a lot. Please see my comment below.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dalthviz, I left my last round of comments. After that, this should be ready.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @dalthviz for your work on this one!
Pull Request Checklist
Developer Certificate of Origin Affirmation
By submitting this Pull Request or typing my name below, I affirm the
I certify the above statement is true and correct: dalthvizDeveloper Certificate of Origin
with respect to both the content of the contribution itself and this post,
and understand I am releasing it under Spyder's MIT (Expat) license.
Description of Changes
Issue(s) Resolved
Fixes #8072
Part of #8068