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.

@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?

@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().