I have to create python parser (3.6) using code provided by client (2.7), that they used in their company, and it is full of crap like:

if a==1:
if not b:
c = [1,2,3]
if a==2:
if not b:
c = [1,2,3]
if b:
c = [1,2,4]

Or:

text = ""
for i in something:
text += "real text " + some_string + " \n"
text += "another line " + some_string + " \n"
text += "and another " + some_string + " \n"
text += "and so on " + some_string + " \n"
... (many lines instead of one appended text block)

Of course above variable names are just for shortening code, but there are variables like oo, ooo, var_ or var__... cause you know, PEP8 does not exist.

PEP is crap anyway.

@AndSoWeCode PEP is just a suggestion, but if someone who wrote this code at least used basic rules it would be easier to rewrite.

@AndSoWeCode for a curious non-python dev, what's wrong with pep?

@iam13islucky my personal problem with it is that when implemented in editors or IDEs, everything becomes just ugly.

The mere fact that they suggest underscores rather than the widely adopted and superior (in terms of length, ease of typing) camelCase, and that because of this idiocy, stuff like Dropbox fail to install on Linux when Python3 is enabled by default, because some 3rd party package has changed its identifiers from PascalCase to underscore to adhere to PEP.

I would understand recommendations in C-like languages, where you could write a whole program without any new lines, and there are tons of debates whether it should be { on new line or not, etc. But this is Python for Apollo's sake, where white space MATTERS.

And like PHP's standards (forgot their name), standardizing the indentation white space to spaces is just stupid.

@AndSoWeCode, my point is that using ANY coding style is a must have, PEP is just most known.

I agree that in Python spaces/indents matter, but that does not mean your code will be readable just becaus you format it properly. Forcing case is up to dev team/client. The most important thing is that you should use proper naming, that gives another dev at least an idea what the hell happens (no x, y variables).

For me it is good that PEP makes you use different format for constants, classes and their attributes. Rules like these makes code even cleaner - if you call a function it is a_function_call(), but when create object it will be SomeObject().
Makes it more self explainatory in many cases compared to CallFunction() along with AnotherObject() or call_function and another_object().

@daegontaven when I'm using pylint, it's highlighting everything that's not strictly in line with PEP. I'd rather not use any linter at all, which in the end makes my code more prone to bad stuff.

I disagree with anything that tells you how to write code, outside of the scope of a single project.

@daegontaven PyLint is but one of many gripes I have.

I realize that PEP is not a language specification so I'm not attacking it as such. However many DO take it as a language specification, which in turns makes people like me, trying to install Dropbox with Python set to default v3, catch a big fail.
And it's not only Dropbox. Issues with breaking changes motivated by PEP (as PEP is a bad recommendation) are way more than that. It's just Dropbox was the latest in my memory.