-
Notifications
You must be signed in to change notification settings - Fork 752
Update handling of breaking around binary operators: W503 vs W504 #498
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Comments
An recent update[1] on PEP8 allows to break a line before a binary operator, until pep8 is updated[2] to reflect to that change, let's ignore it. [1] https://hg.python.org/peps/rev/3857909d7956 [2] PyCQA/pycodestyle#498
How should we implement this patch, interface-wise? There are two options off the top of my head:
|
My opinion is just stop warning and more permissive about continuation line. See discussion in http://bugs.python.org/issue26763 |
I also lean toward not warning about it. It seems like it might be good to warn about mixed styles, but I think ultimately that will be more annoying than helpful. |
#499 is the most straight forward way of solving this. This also allows others who like this rule to re-enable it by selecting it. |
@sigmavirus24 If I understand it correctly, that means there is no way to:
Is it PyCQA's opinion that above points should be pylint's responsibilities? |
@hai-ld please don't put words in my mouth. The immediate need is to turn this off. In my opinion a new check should be added which is also in the default ignore, otherwise we will cause a lot of problems. This means people will need to enable it by hand. (That said, if we wanted to add the new check in pycodestyle 2.0 we could break it very easily.) |
@sigmavirus24 I'm sorry if there's any negative connotation in my comments, be assured that it's not intentional (I'm just not a native English speaker). Since you said "#499 is the most straight forward way of solving this", I thought that was the final solution and asked for confirmation. |
The two comments after yours advocated for not warning about this particular style notion from PEP-0008. In that case, the most straight-forward way to solving the problem of warning about this is to disable it. It's not the end of all discussion though. |
This flips the W503 rule to enforce line breaks before binary operators. Related PyCQA#498
This flips the W503 rule to enforce line breaks before binary operators. Related PyCQA#498
Re-opening to allow discovery of this issue instead of new issues being opened. |
This flips the W503 rule to enforce line breaks before binary operators. Related #498
This flips the W503 rule to enforce line breaks before binary operators. Related #498
Our old version of pep8 produces a warning that goes against the actual pep8 style guide: https://www.python.org/dev/peps/pep-0008/#should-a-line-break-before-or-after-a-binary-operator PyCQA/pycodestyle#498 Change-Id: Iea4612a6608f9de25a1a85c201e5ccc936ec35b7
2.2.0 (2016-11-14) ------------------ Bugs: * Fixed E305 regression caused by PyCQA#400; PyCQA#593 2.1.0 (2016-11-04) ------------------ Changes: * Report E302 for blank lines before an "async def"; PyCQA#556 * Update our list of tested and supported Python versions which are 2.6, 2.7, 3.2, 3.3, 3.4 and 3.5 as well as the nightly Python build and PyPy. * Report E742 and E743 for functions and classes badly named 'l', 'O', or 'I'. * Report E741 on 'global' and 'nonlocal' statements, as well as prohibited single-letter variables. * Deprecated use of `[pep8]` section name in favor of `[pycodestyle]`; PyCQA#591 Bugs: * Fix opt_type AssertionError when using Flake8 2.6.2 and pycodestyle; PyCQA#561 * Require two blank lines after toplevel def, class; PyCQA#536 * Remove accidentally quadratic computation based on the number of colons. This will make pycodestyle faster in some cases; PyCQA#314 2.0.0 (2016-05-31) ------------------ Changes: * Added tox test support for Python 3.5 and pypy3 * Added check E275 for whitespace on `from ... import ...` lines; PyCQA#489 / PyCQA#491 * Added W503 to the list of codes ignored by default ignore list; PyCQA#498 * Removed use of project level `.pep8` configuration file; PyCQA#364 Bugs: * Fixed bug with treating `~` operator as binary; PyCQA#383 / PyCQA#384 * Identify binary operators as unary; PyCQA#484 / PyCQA#485 1.7.0 (2016-01-12) ------------------ Changes: * Reverted the fix in PyCQA#368, "options passed on command line are only ones accepted" feature. This has many unintended consequences in pep8 and flake8 and needs to be reworked when I have more time. * Added support for Python 3.5. (Issue PyCQA#420 & PyCQA#459) * Added support for multi-line config_file option parsing. (Issue PyCQA#429) * Improved parameter parsing. (Issues PyCQA#420 & PyCQA#456) Bugs: * Fixed BytesWarning on Python 3. (Issue PyCQA#459)
Breaks are prefered to occure before rather than after binary operators: PyCQA/pycodestyle#498 W503 has been added to the default ignore list in the latest version, but has to be explicitely specified as we override the default option.
Breaks are prefered to occure before rather than after binary operators: PyCQA/pycodestyle#498 W503 has been added to the default ignore list in the latest version, but has to be explicitely specified as we override the default option.
Breaks are prefered to occure before rather than after binary operators: PyCQA/pycodestyle#498 W503 has been added to the default ignore list in the latest version, but has to be explicitely specified as we override the default option.
Breaks are prefered to occure before rather than after binary operators: PyCQA/pycodestyle#498 W503 has been added to the default ignore list in the latest version, but has to be explicitely specified as we override the default option.
This commit disables warnings W503 and W504. One of these was added to the default ignore list because it wasn't clear, and line breaks conflict with another rule which doesn't allow lines greater than 80 chars. I believe that disabling these rules (W503 + W504) is the cleaner solution. See also discussion here: PyCQA/pycodestyle#498
This commit updates code that was styled to comply with [flake8 rule W503](https://lintlyci.github.io/Flake8Rules/rules/W503.html) to comply with [W504](PyCQA/pycodestyle#498) instead.
We removed all default disabled warnings, but then should add back in W503 and W504 (split after binary operator). See PyCQA/pycodestyle#498
* update pycodestyle to fix broken validation * use raw strings for regexp input to satisfy linter The new version of pycodestyle (2.4.0) requires a few more rules to be satisfied, one of which is Python raw strings for regexp's (which is a good idea IMO). This commit updates the regular expressions that were previously not using raw strings, to use them. * disable line break warnings in pycodestyle This commit disables warnings W503 and W504. One of these was added to the default ignore list because it wasn't clear, and line breaks conflict with another rule which doesn't allow lines greater than 80 chars. I believe that disabling these rules (W503 + W504) is the cleaner solution. See also discussion here: PyCQA/pycodestyle#498 * add test to cover DashConfig.slurp_config_file This ensures the method still works as expected after the raw string change in comment filter regex. * submit new simpler format Trigger objects (#43) * removes remaining SHIM_serialise_for_dashd method (not used any longer) * changes serialization format of triggers submitted to the new format, which changed serialized trigger size in a test and uncovered a bug in the size check * fixes a bug in govobj size limit check in superblock creation (use a temp list to check payments, and only add a proposal to the confirmed payments list after size is checked) * calculate reasonable mock gobject size limit in test This removes the hard-coded max size in the test. Due to the proposal serialization format changing, this hard-coded limit won't work now, and the test should be more robust anyway. * remove trigger size limit * update readme, align w/std-README format (#56) Also remove specific versions to align w/new versioning strategy. * bump version for release (#57)
PEP 8 recommends to break a long line after a binary operator. That's used in the current code. In the past PEP 8 wasn't so specific and W504 appeared in flake8. This one makes flake8 ignore W504. For details see PyCQA/pycodestyle#498
Add upper version constraint to apispec and ignore flake8 warning. PyCQA/pycodestyle#498
Add upper version constraint to apispec and ignore flake8 warning. PyCQA/pycodestyle#498
Based on the discussion that started on python-dev [1] and ended with an update to PEP-8 [2][3], the logic for allowing (preferring really) breaks to occur before rather than after binary operators.
[1] https://mail.python.org/pipermail/python-ideas/2016-April/039774.html
[2] http://bugs.python.org/issue26763
[3] https://hg.python.org/peps/rev/3857909d7956
The text was updated successfully, but these errors were encountered: