setup.cfg

[flake8]
ignore =
    W391  # blank line at end of file
          #     REASON: This rule is extremely trivial and honestly, having an
          #     empty line or two at the end of the file makes it look a bit
          #     nicer IMO, so let's not regulate this
          #
    W504  # line break after binary operator
          #     REASON: Looks like by default, flake8 enables the check for
          #     both W503 "line break before binary operator" and W504 "line
          #     break after binary operator". When both are enabled, it means
          #     one cannot have line breaks around binary operators at all.
          #     I believe the intent is for the user to choose one and ignore
          #     the rule for it. Here we ignore W504 so that we can break
          #     the line after a binary operator
          #
    E501  # line too long
          #     REASON: No need for a linter to enforce this; while we should
          #     try to abide by an 80 character limit, intentionally going over
          #     this by a few characters is a good thing if it makes the code
          #     more readable, and one shouldn't have to fight the linter to
          #     do this. Generally a vertical line drawn at 80 characters in
          #     whatever editor or IDE you have is good enough
          #
    E126  # continuation line over-indented for hanging indent
          #     REASON: This is where I disagree with pycodestyle's
          #     interpretation of PEP8. pycodestyle folks think that any
          #     hanging indent for line continuation should be indented by
          #     only 4 spaces because it ought to be treated like a block,
          #     and blocks are indented 4 spaces. Whereas, nowhere in PEP8
          #     does it say a 'continuation line' and a 'block' is the same
          #     thing. In fact you can easily argue that continuation line and
          #     blocks are very different theoretical concepts. Thus, this is
          #     purely the interpretation of pycodestyle folks and not
          #     necessarily a strong indication of what PEP8 actually intends.
          #     See the discussion at:
          #
          #         https://github.com/PyCQA/pycodestyle/issues/167
          #
          #     In practice, forcing a continuation line to have an indent of
          #     4 characters leads to the following format being the only valid
          #     one:
          #
          #         some_result_variable = my_function(     |
          #             argument_1,                         | max line
          #             argument_2,                         | length
          #             argument_3)                         |
          #
          #     ... which is not ideal because logically, `my_function`
          #     goes together with the arguments, whereas `some_result_variable`
          #     does not, yet visually `some_result_variable` is put next to
          #     the arguments while `my_function` is far away. When visuals
          #     don't match logic, the whole presentation becomes less intuitive
          #     to understand at a glance, and will require more brain power to
          #     parse through.
          #
          #     If we ignore this rule, we can now write it as:
          #
          #         some_result_variable = my_function(     |
          #                                    argument_1,  | max line
          #                                    argument_2,  | length
          #                                    argument_3)  |
          #
          #     ... and this is much nicer to the eye, because the logical
          #     meaning of "left side gets assigned right side" is very clearly
          #     and spatially presented.
          #