Tools should not be named after style guide PEPs. A style guide is a document written for humans, and has lots of subtlety. Issues caused by the rigidity or simplicity of the tool end up causing pointless discussion about the letter of the PEP, as if it was a law, which was never the intention of the PEP. If you want to write a tool that checks style, please give it some clever name, don't name it after a PEP, so it's clear that whenever humans don't like what the tool says, it is a tool issue, not an issue with the PEP (which is merely intended to guide humans, not to require them to follow it every time).

FWIW I am happy that pep8 exist! It can be very useful and I use it myself. But I always let it know who's boss. :-)

Per "suggestion" of @dubglan in https://github.com/jcrocholl/pep8/issues/264#issuecomment-73584055, add the ability to disable warnings on a per file basis (ala pylint). Something like:

# pep8: ignore=EXXX

Is there a planned date for a new release of pycodestyle? This issue for example has been fixed last april, and yet still present on the main release. For direct use of the linter, one can always use the latest master, but it gets complicated to choose pycodestyle version when using it through flake8. It's even worse when using it through even more layers of code, like for example using pre-commit. For example, in our project, we use pre-commit to run black formatter, and then flake8. Black and current flake8-pycodestyle disagree on E252 in function signature with type annotation and we had to silence errors to be able to commit. And as a more general question, what is the release policy of this package?

Contributions to this effort done by:

• Aditya Bhargava
• Calen Pennington
• Hugh Brown
• Chris Angove

Squashed commit of the following:

commit 75b1044e0d5599402eadc65106b68193032fd6b4 Author: Chris Angove [email protected] Date: Mon Apr 16 14:35:33 2012 -0400

fixing issue with a pep8 check that reutrned instead of yielding

commit 3bfee6bbee9ccaa13c4797a62c558ac1d83ad82c Author: Chris Angove [email protected] Date: Mon Apr 16 14:21:59 2012 -0400

fixing pep8 problms

commit f2144460ea8e35750cc3b456c02a6463fe80f9cd Merge: 63aa278 3df8635 Author: Chris Angove [email protected] Date: Mon Apr 16 09:54:00 2012 -0400

Merge remote-tracking branch 'upstream/master'

Conflicts:
    pep8.py
    setup.py

commit 63aa2783bac3960c036e1e29a84a5e2f7595e94f Merge: 826c9cc 5bc7c55 Author: Chris Angove [email protected] Date: Mon Apr 16 06:46:17 2012 -0700

Merge pull request #1 from hughdbrown/master

Fixed a bug in modifying whitespace around named parameters and =

commit 5bc7c55656258be4783a62d2ae053a431e1af289 Author: Hugh Brown [email protected] Date: Sun Apr 15 22:42:22 2012 -0400

Add test for fix in e929e8a

commit e929e8a29631b7d8a769240e74e77bf05c020fdd Author: Hugh Brown [email protected] Date: Sun Apr 15 22:32:37 2012 -0400

Fix whitespace errors
Apply pep8 fixes to pep8.py (why would this never have happened before?)
Fix bug in fixing missing whitespace around named parameters in a call

commit 826c9cc9f3bfca25d8ba8f011f3fff6f76cabf4a Author: Calen Pennington [email protected] Date: Fri Jun 3 10:10:46 2011 -0400

Updating to version 0.6.2

commit ca139634643bd8282ab8c4b30b72149a69a8319f Author: Calen Pennington [email protected] Date: Fri May 27 15:08:33 2011 -0400

Only open/write to file if there are changes to be made to it

commit 756457c3dd15506f7cc49686d6c49b3313ae626e Author: Calen Pennington [email protected] Date: Fri May 27 14:59:24 2011 -0400

Skip edits that will conflict

commit ed1b45b73ec49cbcad79055f9fae25e7d019dce3 Author: Calen Pennington [email protected] Date: Fri May 27 13:15:12 2011 -0400

Adding fixes for more checks

commit 2fcd046abade4a3b38f9769d54c9adf8fd9d7be1 Author: Calen Pennington [email protected] Date: Fri May 27 12:29:22 2011 -0400

Adding selftests for the fix_* functions

commit f7272dbb4ad6168833a0c728e7375e3a068aa8e9 Author: Calen Pennington [email protected] Date: Fri May 27 09:04:57 2011 -0400

Make fix code work for tests with no fix attached

commit e01c7626ed568a71cccc2898f075a4c6b5e7b869 Author: Calen Pennington [email protected] Date: Fri May 27 09:04:20 2011 -0400

Add fix for whitespace_before_parameters

commit da39c3369858c0a1c579464782d722557a45138a Author: Calen Pennington [email protected] Date: Fri May 27 09:04:06 2011 -0400

Add test for missing_whitespace

commit 874b65dd2e30b1bf343601a2a2eab4f096adde26 Author: Calen Pennington [email protected] Date: Fri May 27 09:03:54 2011 -0400

Make fix_extraneous_whitespace work with tabs and spaces

commit 3e44076e394290f31509b3398672128fe6cface0 Author: Calen Pennington [email protected] Date: Fri May 27 08:47:51 2011 -0400

Allow logical checks to yield more than one error per line

commit 203fb20fd9d9d857353d5298fc54de54719fbbed Author: Calen Pennington [email protected] Date: Fri May 27 08:31:57 2011 -0400

Adding fix for extraneous_whitespace

commit 1c58077454359c32cccd55681ac4fa7d91bc557c Author: Calen Pennington [email protected] Date: Fri May 27 08:31:41 2011 -0400

Adding fix for blank_lines

commit 32d37342ec7dae4413947cb0bc7b4a2447da5a9e Author: Calen Pennington [email protected] Date: Fri May 27 08:31:28 2011 -0400

Adding fix for missing_newline

commit c0553094191d859a13892d41f0cb8312079d117e Author: Calen Pennington [email protected] Date: Fri May 27 08:31:12 2011 -0400

Adding fix for trailing_blank_lines

commit 810318f2e1f5490c407ce238f499d5cf94ec2b1f Author: Calen Pennington [email protected] Date: Fri May 27 08:30:14 2011 -0400

Add fix for trailing_whitespace

commit d8f990049224105cef882d2824956ae07b911a7e Author: Calen Pennington [email protected] Date: Fri May 27 08:30:01 2011 -0400

Add fix for tabs_obsolete

commit 7244dcf1e6bdb0513be1a389a8d488e16cbaa0a0 Author: Calen Pennington [email protected] Date: Fri May 27 08:29:24 2011 -0400

Add the mechanism for making fixes as easy to add as checks

commit 0ad68e67ed758d57ea9c9512c086d63a3376a96c Author: Calen Pennington [email protected] Date: Fri May 27 08:28:12 2011 -0400

Fix reporting of IOErrors during fix output

commit 2185e866a1380f20e24713ee4a8a5af979769e43 Merge: 29968a6 6b87796 Author: Calen Pennington [email protected] Date: Thu May 26 16:19:05 2011 -0400

Merge changes from https://github.com/egonSchiele/pep8/commit/6b87796987dadf7f872dc390fb31bc71add05407

Conflicts:
    pep8.py

commit 6b87796987dadf7f872dc390fb31bc71add05407 Author: Aditya Bhargava [email protected] Date: Thu Apr 8 22:56:33 2010 -0500

--inplace flag added to allow changes to files in-place. try/catch block added for write file.

commit c01c47bdd351cc68fbf641af42c5aebfbde240b3 Author: Aditya Bhargava [email protected] Date: Wed Apr 7 17:10:44 2010 -0500

fix functionality added for trailing whitespace and superfluous blank lines at the end of the file.

commit 6c6e01edcbb0d8a823311b3fd95debb2ff9d30ff Author: Aditya Bhargava [email protected] Date: Wed Apr 7 16:45:22 2010 -0500

some fix functionality added. Now pep8 can be used to fix certain issues to be consistent with PEP 8.

2.4 release broke AttributeError: 'module' object has no attribute 'break_around_binary_operator' see https://travis-ci.org/EBI-Metagenomics/emgapi/jobs/364572048#L637

PEP8 states:

For flowing long blocks of text with fewer structural restrictions (docstrings or comments), the line length should be limited to 72 characters.

The current implementation only enforces the maximum line length (E501). I'd like to suggest the addition of an E503 error to enforce the restriction of these "flowing long blocks of text."

From what I could see, there is no advice in PEP-8 to discourage using closing parens on the same line as the last item in a list, e.g.

foo = {
       "bar": (
           "baz",
           "qux"
           )  # <-- this is discouraged
       }  # <-- as is this (n.b. it is one column to the right)

This is the default indentation style in emacs.

pep8 says: E123 closing bracket does not match indentation of opening bracket's line

Sometimes we need to violate PEP8 rules to improve readability of source file, at the same time we would like file to be still checked by PEP8.

I've added simple change that allows to influence pep8 'expected' codes:

:PEP8 -E221 -W603

a = 3 long = 4

:PEP8 +E221

Prepending minus sign disables the code, while prepending plus enables it back.

Please let me know if that makes sense for inclusion, I may need to add tests...

An implementation of #344.

This implementation takes the effective default of 79 characters for the default max doc length despite PEP8 recommendations being 72, as well as setting only a warning. In addition, W504 is added to the default ignore list.

Builds tested with py27 and py35 (don't have others on my platform, sorry!)

I ran pep8 over the "this is OK" examples in PEP 8, and found the following false alarms with pep8's default settings:

E121 (requiring continuation lines to use 4 space indents is not in PEP 8 - that guideline only applies to suite indents) E701 (PEP 8 allows single line compound statements, and uses one as the preferred alternative to having a lambda expression on the RHS of an assignment statement)

not importing files at top is a PEP8 violation.

http://legacy.python.org/dev/peps/pep-0008/ Imports are always put at the top of the file, just after any module comments and docstrings, and before module globals and constants.

Not flagged in current Pycharm... rerouted from Pycharm per their request

Fixes #951

Done by tracking enclosure count when inside a function param list (detected by def keyword) and checking whether the previous token's text is , to be sure that the currently checked token can be evaluated in a param name context.

so #1041 brought up a lot more instances of E721 and I don't feel confident adding this in a release since it's going to cause a bunch of (imo) unnecessary work

for example, here's something which wasn't flagged before but is now:

assert type(x) is not bytes

strictly speaking the lint rule probably should match this, but almost every case I can find with is and is not is being very explicit about the types being checked

I think the most reasonable thing to do here is to only check == and != -- those are the ones that are most likely actual mistakes rather than an explicit check.

the other option is revert #1041 -- which might be the quickest thing to do to not block a release -- unclear what the best approach is here

fixes #1061 Changed out the current implementation of lambda assignment detection for a regex based one. As stated in #1061, there are several lambda assignment cases that are being missed. Additionally, the current detection implementation is not in the most logical place. Before, detection of lambdas was tied to searching for ':' characters. Now lambda assignment statements are all just detected by:

(?<!\.)\w+\s*(\,\s*\w+\s*)*\=(.*\,)*[\s|\(]*lambda

This implementation has more coverage and is more simple than the previous one.

a = lambda x: x  # Raises E731
a = (
    lambda x: x 
) # Doesn't raise E731
a, b = lambda x: x, lambda y: y  # Doesn't raise E731
a, b = 1, lambda y: y  # Doesn't raise E731

Warehouse now uses the project_urls provided to display links in the sidebar on this screen, as well as including them in API responses to help the automation tool find the source code for Requests.