Python PEP8: Practice what you preach

Generated by Gemini

Note: if you are not a member of Medium, just read it fully here.

Back in 2001, PEP8 was introduced to the Python community. A set rules on how to write stylish Python. The guide was partially written by Guido himself … so in my tour of duty as software engineer I met quite a few zealots about it.

You know, people with little or no knowledge that wanted to make some remarks on your code … hah … kidding. But they were zealots, that was a fact.

To be honest, I am not a big fan of such standards. I consider that they overreach and suppress individual style, but on the other hand if you have a large team, you need a set of standards.

A Simple Observation

During my various projects in Python, I noticed that the standard library that was distributed along with each version did not seem to follow any standard. I noticed camel-case style in some libraries and snake-case to some others.

So, I found a good idea to check if actually the libraries follow that. For this purpose I used ruff . A well-known tool that checks your Python code for many violations, among them PEP8.

The Process

After a bit of searching I found out that all Python versions are available in https://www.python.org/ftp/python. The idea is to check versions ≥ 3.0.0 , but I am pretty sure that the previous versions follow the same patterns.

The rest is easy, a simple Python script is enough. Fetch the archives for each version, decompress it and run ruff. You can find that script available here. You can just run it with the command:

uv run gather_version_data.py

The results are generated in the results directory.

The Results

The script found in total 182 versions. from 3.0.1 => 3.14.0 . Each files contain entries like the following one.

E702 Multiple statements on one line (semicolon)
 --> work/Python-3.0.1/Demo/cgi/cgi2.py:5:13
  |
3 | """CGI test 2 - basic use of cgi module."""
4 |
5 | import cgitb; cgitb.enable()
  |             ^
6 |
7 | import cgi
  |

In short, these are the distinct set of rules that are violated in all versions:

E401: Multiple imports on one line
E402: Module level import not at top of file.
E501: Line too long.
E701: Multiple statements on one line (colon).
E702: Multiple statements on one line (semicolon).
E703: Statement ends with a semicolon.
E711: Comparison to None should be is None.
E712: Comparison to True (or False) should be if cond: (or if not cond:).
E713: Test for membership should be not in.
E714: Test for object identity should be is not.
E721: Do not compare types, use isinstance().
E722: Do not use bare except:.
E731: Do not assign a lambda expression, use a def.
E741: Ambiguous variable name.
E742: Ambiguous class name.
E743: Ambiguous function name.

Ouch, it seems that its violating a bunch. Most of them refer to readability and only a handful are (or at least they seem) dangerous.

On average each version has the following number of errors:

Calculate average errors per file
3.0.*: avg Errors: 4479
3.1.*: avg Errors: 4619
3.2.*: avg Errors: 4811.83
3.3.*: avg Errors: 4999.75
3.4.*: avg Errors: 5278
3.5.*: avg Errors: 5377.36
3.6.*: avg Errors: 4937.81
3.7.*: avg Errors: 5134.17
3.8.*: avg Errors: 5461
3.9.*: avg Errors: 5745.69
3.10.*: avg Errors: 5964.4
3.11.*: avg Errors: 6130.53
3.12.*: avg Errors: 6112.54
3.13.*: avg Errors: 8403
3.14.*: avg Errors: 16560

We can see that it is increasing, so according to the Python’s PEP8 the quality is falling.

Conclusions

The above results have two possible explanations:

1. PEP8 is not that important :) … and nobody cares.
2. The standard Lib of Python is less and less readable and Pythonic.

I like Python very much as a technology stack and as a language, but I have to admit that it has a bit of hacky nature on all aspects of the development lifecycle.

Keep a look at the repo, because I will add more and more data in the near future.