I think that PEP8 is a great guideline for good readability. Almost every piece of software I write is PEP8 compliant and reading non compliant software is quite discouraging for me if I’d like to send a patch or contribute in some way.
I think that having a common style in every python code could increase readibility, remove the need of adapt to different styles and make contributing and patching easier.

@Luke Plant: you make some good points. I’ll try to address them in a second post if I can find the time today.

While I love beautiful code, someone waltzing in and dissing something I posted due to it not being PEP8 makes me want to pull out my hair. It’s often just distracting from the main issue, like complaining about there not being any cream-filled donuts in the Krispy Kreme box at the meeting.

When there is already overwhelming standardisation on PEP8 for Python projects (at least for new projects), very few people will take the effort to configure their habits and editors to adjust to your style. Some editors often don’t make it easy to do anything but 4-spaces for indentations, since this is the default for Python and almost everyone sticks to it.

“Readability counts” is deeply embedded philosophy in the Python community, and sticking to standard conventions is extremely helpful to readability:

If I know that CAPITALS are generally constants, for example, I’m going to be stumped and caught out every time some code violates that. The same is true of matters of whitespace in code - whitespace gives strong hints that help me as I read, and every violation of the normal convention is a speed bump that will trip me up.

So, when you ignore these conventions, most people, myself included, will tend to conclude that 1) you disagree with the Zen of Python and 2) you don’t care about other people who might read it. On that basis, I would 1) avoid using your code due to concerns about its general quality and 2) not bother to contribute back, because you don’t seem to be a team player (where ‘team’ includes the rest of the Python world).

If that’s what you want, that’s fine, but I think you need to be aware of the signal you are sending. A good developer is always ready to sacrifice small personal habits for the benefit of people who will read their code, and this is one of the primary qualities I would look for in developers I want to work with.

For example, I like functional style, and think use of map and filter are often more elegant that list comprehensions, even if you need to create a lambda on the fly to get the function you want. However, in the Python community I’ll normally use a list comprehension (unless there is a pre-existing function I can pass to map or filter that does exactly what I want).

In the days of github and bitbucket, when for small projects you will want to be able to fork it in seconds and contribute patches in minutes, do you really think that people want to learn your specific coding style before contributing?

Further, I’d say that the argument that you’ve used this style with lots of other platforms and languages counts against you - it says that you are going to program the same way no matter what the change in environment, rather than adapt. This might not be true of course - but it’s the impression you are giving.

The hardest thing for me to adopt was the absurdly short line length. Since I’m no longer writing code on a VT52 terminal, I relished the freedom of typing beyond the 79th character.

Parallel with the trend of having tube based amplifiers to drive speakers on MP3 players, I suppose that PEP8’s line length restriction is to accommodate the return of programming on punch cards.