On Mon, 31 Dec 2007 12:36:11 +1100, Ben Finney wrote: > Steven D'Aprano <[EMAIL PROTECTED]> writes: > >> On Sun, 30 Dec 2007 20:41:09 +0000, Thorsten Kampe wrote: >> >> > Anyway: the consequence of your well done argumentation is that >> > someone editing Python code has to use a specialised editor to >> > prevent screwing up tab indented code - and that's bad. >> >> You just need to use an editor that inserts tab characters when the tab >> key is pressed, just like you use an editor that inserts s characters >> when the s key is pressed. > > No, that's not all you need to do. You also need to keep your code away > from the majority of programmers, who use their default editor in its > default settings
I question that. On my system at least (Fedora 7), here are the default settings on the editors I have available: vi default is tab character emacs default is tab character gedit default is tab character nano default is tab character joe default is tab character kedit always uses tab character kwrite default is tab character kate default is tab character scribes default is tab character eclipse default is tab character With every Linux distro being slightly different, your mileage may vary, but with not even a single editor on my system defaulting to spaces, I hope you can excuse my skepticism. And if you extend your view to the 90% of the computing world that doesn't use a Unix-like operating system, we can consider: VisualStudio default is tab character Epsilon default is tab character Notepad always uses tab character Wordpad always uses tab character No doubt there are a hundred other Windows text editors, but I'm not familiar with them. Nor am I familiar with OS X based text editors, although back in the 1990s Apple Mac text editors invariably inserted a tab when you pressed the tab key. > and who expect that horizontal whitespace is produced > by the U+0020 space character (even if they don't know the specifics of > the character coding). > > Saying that the tabs-only argument and the spaces-only argument are of > equal value is philosophically true, but practically worthless. They're > of equal value *only* in isolated environments where you can control the > expectations of *every* programmer who will *ever* edit the file. Ah, and now we're getting somewhere! It's not so much that tabs are intrinsically harmful (as people like Thorsten keep insisting), but that in a world supposedly dominated by people who indent with spaces, using tabs might lead to inconsiderate programmers ignoring your project's coding standards and inserting spaces into your code base. Yes, I can see that is a problem. I believe it is best solved by refusing contributions from such inconsiderate programmers. After all, if they're going to ignore your project's code standards in one aspect, they're invariably going to ignore others as well. Ben, I'm surprised that you of all people should take such a pragmatic view that "tabs are bad because the majority use spaces". By that reasoning, you should be driving a SUV (much safer than riding a bike!), sending HTML-only emails written in Outlook (with Word as your editor naturally) and publishing data solely in proprietary binary formats like .doc. Everybody else does it, why buck the trend? There's a very good reason to buck the trend whenever practical: tabs have the considerable benefit that they decouple the presentation of the code from the structure of the code. When you use tabs to indent code, the reader can place their tab stops where ever they wish, according to their own needs and preferences: every eight spaces, or four, or three, or twenty-seven spaces if they want. One tab means one indent level (structure), and the width of that indent (presentation) is up to the reader. But when you use spaces, you are essentially forcing your presentation onto all your readers, whatever their wishes. Sure, some editors let you re-indent code at the press of a button, and some of them might even get it right more often than not -- but for Python at least, if you want to contribute code back to the project, you can't afford to do that. You're stuck using whatever presentation the project manager chooses. Using spaces is fundamentally broken because it turns a structural single level of indentation into a presentational four spaces -- or eight, or two, or five, whatever the project's coding standard insists on. > To form an indentation policy based only on hypothetical > fully-controlled isolated environments is foolish, to say the least. Just say I'm tilting at windmills. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
