Which PEP's are must reads?

Question

I'm a fairly strong Python coder, but too much of my style is a little haphazard, and I'm sure there are more Pythonic solutions to many problems than the ones I come up with. Which PEPs are essential for any well versed Pythonista to read?

Scorbutic

python.org/dev/peps – Johnie

should be community wiki – Triturable

Answer 1

Definitely PEP 8, a Style Guide for Python.

Ezarra

Use a heavy dose of common sense when reading it. Ignore the section about "79 characters" entirely; it's braindamaged and leads to ugly, hard-to-read code for no real-world benefit (this was written in 2001 and sane development systems weren't 80x25 even then). The horrors of the "Rectangle" example show the problem very clearly. – Bootlace

Despite of my 22" screen, all my editor/terminal windows are fixed to 80 chars and I try to write the code accordingly. (But, as Terry Pratchett puts it, rules are to make you think before breaking them.) – Flacon

PEP 8 was originally written n 2001, but updated many times since then. If 80 columns weren't important any more, then it would probably have been removed. hg.python.org/peps/log/5dceea0aaa49/pep-0008.txt – Yeargain

A line more than 80 chars usually is ugly by itself. It is not a criticism about you, @Gleen, however, because it is often needed and practicality beats purity :) – Levitus

I happen to be reading this way late -- but assuming others will be as well; Pep 3099 addresses the 80 chars issue, emphatically stating that it is not going away (at least as a recommendation); See way down near the bottom, under coding style; python.org/dev/peps/pep-3099 – Sheridansherie

Answer 2

Although Python is incredibly intuitive, a lot of people do not comprehend his philosophy.

Pep 20: The Zen of Python

• Beautiful is better than ugly.
• Explicit is better than implicit.
• Simple is better than complex.
• Complex is better than complicated.
• Flat is better than nested.
• Sparse is better than dense.
• Readability counts.
• Special cases aren't special enough to break the rules.
• Although practicality beats purity.
• Errors should never pass silently.
• Unless explicitly silenced.
• In the face of ambiguity, refuse the temptation to guess.
• There should be one-- and preferably only one --obvious way to do it.
• Although that way may not be obvious at first unless you're Dutch.
• Now is better than never.
• Although never is often better than right now.
• If the implementation is hard to explain, it's a bad idea.
• If the implementation is easy to explain, it may be a good idea.
• Namespaces are one honking great idea -- let's do more of those!

Pinch

Answer 3

It is now retrospective, but still interesting: I think Things that will Not Change in Python 3000 is a good read, with lots of links to the discussions that preceded the decisions.

Johnie

Answer 4

Also pep 0257 docstring convention

Lanni

Answer 5

I found that reading the declined ones can give some good insights into what's Pythonic and what isn't. This was a while ago so I don't have any specific examples.

Pelerine

Answer 6

I'd also recommend PEPs 8 and 257. I know this deviates slightly from the original question, but I'd like to point out that PyCharm (probably the best Python IDE around in my opinion) automatically checks if you're following some of the most important PEP 8 guidelines, just in case anyone's interested...

Winkelman

Answer 7

Here is a index of PEP - http://www.python.org/dev/peps/

when ever one has doubt about a topic, they can search in that

Accelerometer