Py3k letters - Part I, The PEP Talk

This post is all PEP-talk. What pep talk you may ask ? Well not the usual pep-talk but talk about PEPs. "PEP" stands for "Python Enhancement Proposals" and is the way in which Python language developers and enthusiasts go about suggesting, agreeing on and incorporating changes to the Python language.

For Python 3.0, the key PEP is PEP 3000. All Py3k PEPs are numbered starting from 3000 upwards. PEPs 3000-3099 are special, since they are PEPs about PEPs, so called "meta-PEPs". PEP 3000 is like the god of all meta-PEPs, since it is meta-PEP of all meta-PEPs. Think about it something like the father of all meta-PEPs, the originator, the source.

There are two more PEPs which are special. PEP 3099 and PEP 3100. The former is an anti-thesis of a PEP actually, since it refuses to budge - it is a list of things that has no plans of changing in Py3k. Interesting isn't it ?

The latter is the mirror image of the former. It is a laundry list of things that will change in Py3k, which are not big enough to have a PEP of their own. The fact that it follows PEP3099 is not its fault. It just so happens. In fact, this PEP was christened as PEP3000, but as other PEPs were born and began to strive for space and the PEP talk became more and more noisy, the BDFL and his gang of merry men re-christened this PEP all the way up by a century. I am not sure why this happened, but that is history and one cannot change it. However the PEP is not complaining and neither should you. Strange are often the ways of PEP-land...

Now, Py3k was not born as an idea in a single day (neither was Rome built in one), so you can imagine that there was a lot of pep-talk which led to its conception. And though PEP-land is often strange in its ways, it is not as strange as to defy logic completely - it is not. You would expect these PEPs to be older than the one which is bears the name 3000 in its birth certificate, and you would be right if you thought so.

These older PEPs, which are the big brothers of PEP 3000, influenced the growth of PEP 3000. From older to younger, they are,

1. PEP 238, which divided the kingdom of Pythonistas over the something as simple as the division operator. The contention was how to float and divide at the same time, in just one swoop. It turned out that that this was a hard problem to solve and finally after many a battle, the decision was made - float and divide in a single swoop and only divide in two swoops . The ramifications of this decision will be huge for many programs which are inhabitants of the Python land, especially belonging to the numerical and scientific family trees.

2. PEP 328, which made a lot of funny noise with statements that is any combination of the strings "from", "import", ".", "..", and "as" . All to solve the problem of the right syntax of relative imports - that is imports as in importing code, not like importing sugar or oil, which is a more easier problem to solve apparently. This problem is much more abstruse, and aims to bring down packages from folders they live in, relative to the current folder.

3. PEP 343, which is all about disciplining the brat fraternity of "try", "except" and "finally" statements, by giving them some meaning in life (a "context" actually) and holding them together with a "with" statement. Matters get complicated when a context is managed with a contextmanager, as usually happens when managers get involved in any engineering problem.

4. PEP 352, which is about installing an original ancestor for a group of dangerous characters, whose main job is to raise issues which are euphemistically called as "exceptions". Unfortunately, chaos has reigned at the top of this hierarchy with no clearly defined ancestor who these characters can claim lineage to. Pythonistas realized (quite late) that it is dangerous to let the status quo remain and the pep-talk resulted in this PEP which aims to fix the status for good by correcting their ancestor tree. Very well. I am glad we cannot do these things in real life.


So, all the talk about pep-talk has resulted in the above peppy PEPs. Pythonistas live and swear by PEPs, so if you want to learn the Py3k way, you should walk the way of the PEPs for some time and live with them, understanding why and how they exist.

The above PEPs form the soul and core of Py3k, so get used to them and we will discuss the actual issues they solve and how they do it, starting from Part 2 of the Py3k letters. Till then happy PEPing.

Py3k letters - Part 0

Python 3.0 (py3k) is on the way. The 3.0 version is going to be a significant update in the Python programming language, considering that it is almost 8 years since the release of the last major version, Python 2.0, which was released in Oct 2000.

Py3k is going to change the way the Python programmer goes about his work in many ways, with some significant "in-your-face" changes and many thousands of changes and fixes below the layers and quite some just in between.

I am starting a series of blog posts from today, which will focus on Python 3.0, specifically on the major changes in the language when compared to Python 2.x versions. The plan is to cover enough areas (hopefully), so that by the time py3k is released in August this year, there will be enough text here to serve as an aid to Python programmers in chartering py3k territory.

With that introduction, on to the "py3k letters" series, with the first edition coming in the next post. Keep tuned in.