Permalink
Cannot retrieve contributors at this time
96 lines (78 sloc)
3.92 KB
Name already in use
A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?
peps/pep-0666.txt
Go to fileThis commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| PEP: 666 | |
| Title: Reject Foolish Indentation | |
| Author: Laura Creighton <lac@strakt.com> | |
| Status: Rejected | |
| Type: Standards Track | |
| Content-Type: text/x-rst | |
| Created: 03-Dec-2001 | |
| Python-Version: 2.2 | |
| Post-History: 05-Dec-2001 | |
| Abstract | |
| ======== | |
| Everybody agrees that mixing tabs and spaces is a bad idea. Some | |
| people want more than this. I propose that we let people define | |
| whatever Python behaviour they want, so it will only run the way | |
| they like it, and will not run the way they don't like it. We | |
| will do this with a command line switch. Programs that aren't | |
| formatted the way the programmer wants things will raise | |
| ``IndentationError``. | |
| - ``python -TNone`` will refuse to run when there are any tabs. | |
| - ``python -Tn`` will refuse to run when tabs are not exactly ``n`` spaces | |
| - ``python -TOnly`` will refuse to run when blocks are indented by anything | |
| other than tabs | |
| People who mix tabs and spaces, naturally, will find that their | |
| programs do not run. Alas, we haven't found a way to give them an | |
| electric shock as from a cattle prod remotely. (Though if somebody | |
| finds out a way to do this, I will be pleased to add this option to | |
| the PEP.) | |
| Rationale | |
| ========= | |
| Python-list@python.org (a.k.a. comp.lang.python) is periodically | |
| awash with discussions about tabs and spaces. This is inevitable, | |
| given that indentation is syntactically significant in Python. | |
| This has never solved anything, and just makes various people | |
| frustrated and angry. Eventually they start saying rude things to | |
| each other which is sad for all of us. And it is also sad that | |
| they are wasting their valuable time which they could spend | |
| creating something with Python. Moreover, for the Python community | |
| as a whole, from a public relations point of view, this is quite | |
| unfortunate. The people who aren't posting about tabs and spaces, | |
| are, (unsurprisingly) invisible, while the people who are posting | |
| make the rest of us look somewhat foolish. | |
| The problem is that there is no polite way to say 'Stop wasting | |
| your valuable time and mine.' People who are already in the middle | |
| of a flame war are not well disposed to believe that you are acting | |
| out of compassion for them, and quite rightly insist that their own | |
| time is their own to do with as they please. They are stuck like | |
| flies in treacle in this wretched argument, and it is self-evident | |
| that they cannot disengage or they would have already done so. | |
| But today I had to spend time cleaning my keyboard because the 'n' | |
| key is sticking. So, in addition to feeling compassion for these | |
| people, I am pretty annoyed. I figure if I make this PEP, we can | |
| then ask Guido to quickly reject it, and then when this argument | |
| next starts up again, we can say 'Guido isn't changing things to | |
| suit the tab-haters or the only-tabbers, so this conversation is a | |
| waste of time.' Then everybody can quietly believe that a) they | |
| are correct and b) other people are fools and c) they are | |
| undeniably fortunate to not have to share a lab with idiots, (which | |
| is something the arguers could do _now_, but apparently have | |
| forgotten). | |
| And python-list can go back to worrying if it is too smug, rather | |
| than whether it is too hostile for newcomers. Possibly somebody | |
| could get around to explaining to me what is the difference between | |
| ``__getattr__`` and ``__getattribute__`` in non-Classic classes in 2.2, a | |
| question I have foolishly posted in the middle of the current tab | |
| thread. I would like to know the answer to that question [1]_. | |
| This proposal, if accepted, will probably mean a heck of a lot of | |
| work for somebody. But since I don't want it accepted, I don't | |
| care. | |
| References | |
| ========== | |
| .. [1] Tim Peters already has (private correspondence). My early 2.2 | |
| didn't have a ``__getattribute__``, and ``__getattr__`` was | |
| implemented like ``__getattribute__`` now is. This has been | |
| fixed. The important conclusion is that my Decorator Pattern | |
| is safe and all is right with the world. | |
| Copyright | |
| ========= | |
| This document has been placed in the public domain. |