Do You PEP?

Short new series for me. Quick and Dirty Programming Posts They’ll be tagged qdpp. They’ll be raw, error prone and mostly works in progress.

A few reasons

• to help me write for a few minutes (publicly) daily. I’ve realised slow and steady is a good way to build a body of work, (Godin, Kushal). Even if the beginning is slow and shitty.
• to save myself searching the web for stuff I need to have handy.
• these are primarily for me, and me alone. If they help you as well, that’s a bonus!

Let’s start with PEP.

I’ve learnt that to learn anything well, it’s best to learn from the source. Go to the well. Don’t read about the Black Swan, or try to figure out from blogs what Antifragility is. Go read the darned Incerto! So when it comes to programming, I should do the same.

¹

And everytime I learn something new with Python, I’m referred to a PEP as the source.

• When is Python 3.7 out? Check the PEP.
• What on God’s green earth are docstrings? Check the PEP.
• Will PyPI crumble under its own weight? Or will there be redundant options? Check the PEP.
• How do you write Python so that it’s comprehensible? Readable? Is there a style guide of sorts? Check the PEP.
• A short treatise on what Python is about? Its Zen if you will? Check the PEP.
• What is a PEP? Go, check the PEP!

So, a PEP (Python Enhancement Proposal) is a design document,

• providing information to the Python community,
• or describing a new feature for Python or its processes or environment. They’re worked on, one itty bitty version at a time. You can see how they come alive and grow here. They describe standards, share information, and describe processes on things other than code too (like PEP-8)

And as to why, the very first one explains it much better than I ever could.

So if you must know, where the Python rabbit hole conclusively ends, it most probably does in a PEP.