Re: Tabs versus Spaces in Source Code
Harry George wrote: > The reason is simple: People get confused, and accidentally get the > wrong tab indents when they move among editors or among settings on > the same editor. People certainly do get confused. I'm always amazed that so many people, even amongst those who manage to make a living out of writing software, are unable to grasp the concept of a tab. But then a lot of code is badly written, so maybe it figures. A tab is not equivalent to a number of spaces. It is a character signifying an indent, just like the newline character signifies the end of a line. If your editor automatically converts tabs to spaces (i.e. you are unable to create source files containing tabs) then either it's broken or you have misconfigured it. Either way you probably shouldn't be using it to write code. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs versus Spaces in Source Code
Duncan Booth wrote: >but I prefer editors which keep things >simple. The tab key is particularly prone to excessively complicated >actions, for example the editor I use has the following (not simple at >all, and in fact not even an accurate description of what it does) binding >for the tab key: I'm not familiar with your editor, but if that's its default behaviour when you hit tab then it sounds neither simple nor intuitive. You haven't explained why you think there's a problem with having a character which, in an unambiguous and non-implementation-specific way, means 'one level of indentation'. In Python, of all languages, it makes sense to have such a character because 'one level of indentation' is a syntactical token processed by the interpreter. But consider this: like all real men, I normally program in hex. Here's an example of some recent code: 0x66 0x6f 0x72 0x20 0x69 0x74 0x65 0x6d 0x20 0x69 0x6e 0x20 0x6d 0x65 0x6e 0x75 0x3a 0x0d 0x0a 0x09 0x70 0x72 0x69 0x6e 0x74 0x20 0x27 0x73 0x70 0x61 0x6d 0x27 0x0d 0x0a 0x70 0x72 0x69 0x6e 0x74 0x20 0x27 0x6c 0x6f 0x76 0x65 0x6c 0x79 0x20 0x73 0x70 0x61 0x6d 0x27 If I wanted to be girly about it I could use an editor, and it would probably look like this: for item in menu: print 'spam' print 'lovely spam' But then if I wanted, I could write my own editor, and make it display tabs as 'negative indents' from column 40, so that it looks like this: for item in menu: print 'spam' print 'lovely spam' Guess what: the python interpreter wouldn't know about my strange editor habits! It would read my file and run just fine. What's more you can view it with *your preferred indentation display methodology* and we can both live in harmony! With spaces for indentation, this just isn't possible, because I have to conform to your viewing preferences, and that makes me unhappy. Why would you want to make me unhappy? -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs versus Spaces in Source Code
Kaz Kylheku wrote: > If you want to do nice typesetting of code, you have to add markup > which has to be stripped away if you actually want to run the code. Typesetting code is not a helpful activity outside of the publishing industry. You might like the results of your typsetting; I happen not to. You probably wouldn't like mine. Does that mean we shouldn't work together? Only if you insist on forcing me to conform to your way of displaying code. You are correct in pointing out that tabs don't allow for 'alignment' of the sort you mention: (lisp (nested list with symbols and things)) But then neither does Python. I happen to think that's a feature. (And of course you can do what you like inside a comment. That's because tabs are for indentation, and indentation is meanigless in that context. Spaces are exactly what you should use then. I may or may not like your layout, but it won't break anything when we merge our code.) -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs versus Spaces in Source Code
Duncan Booth wrote: >Because it doesn't mean 'one level of indentation', it means 'move to next >tabstop' and a tabstop isn't necessarily the same as a level of >indentation. 'move to next tabstop' is how your editor interprets a tab character. 'one level of indentation' is how the language parser interprets it. The two are entirely consistent, in that they are both isomorphic mappings of the same source file. >In particular a common convention is to have indentations at 4 >spaces and tabs expanding to 8 spaces. Like all space-indenters, you seem to be hung up on the idea of a tab 'expanding' to n spaces. It only does that if you make your editor delete the tab character and replace it with spaces! Really, that is the only sense in which your statement makes any sense. If you want your indentation to have the width of four, eight, or nineteen spaces, set your tabstops accordingly. Seriously people, this is about separating the content of a source file from how it is displayed. It's about letting people work together while also allowing them to have control over their own environments, something which is and always has been central to the hacker ethos. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs versus Spaces in Source Code
Duncan Booth wrote: >However the important thing is that a tab does >not map to a single indentation level in Python: it can map to any number >of indents, and unless I know the convention you are using to display the >tabs I cannot know how many indents are equivalent to a tabstop. Sorry but this is just wrong. Python works out the indentation level for a source file dynamically: see http://docs.python.org/ref/indentation.html. The particular algorithm it uses is designed to accommodate people who mix tabs and spaces (which is unfortunate, and should probably be changed). Nevertheless, using tabs only, one tab does indeed map to exactly one indentation level. One tabstop == one indent, on your editor and on mine. You do not need to know my display convention to run my code. All I can suggest is that you try it out: create a short source file indented with tabs only, and play around with your editor's tabstop setting (and make sure it is writing tab characters, not spaces, to the source file). I promise you the Python interpreter will neither know nor care what your editor display settings were when you last wrote the file. I realise that a lot of code out there uses spaces only. That's unfortunate, but it doesn't mean we should stop explaining to people why tab-indenting is a better standard. This is about freedom: indenting with spaces lets you control over how other people view your code; indenting with tabs give them that control. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs versus Spaces in Source Code
Iain King wrote: >python -tt Indeed. I reckon the consensus here (to the extent that there is any!) is that it would be better if this was Python's default behaviour. The argument (not advanced by Iain but by others in this thread) that: novices will mix tabs and spaces => we should all use spaces only is clearly false by symmetry. An alternative solution to this issue would be to write an editor plugin which converted between space-indented and tab-indented Python source files on opening *and back again* on writing or closing. Then we would have: Case 1: you send me a space-indented file. My editor opens the file, finds that it is space-indented, calculates the indentation level of each line and converts it to the corresponding number of tabs, and then writes that to a temporary file which it then displays for editing. On writing, it converts indentation back to spaces and writes to the original file. Case 2: I send you a tab-indented file. As Case 1 with s/tab/space/; s/My/Your/ Case 3: You send me a file with mixed tab/space indentation Everything borks, as it should. It's horrible but at least it would insulate me from the greater hideousness of having to hit the spacebar like a madman at the start of every line of code. I can even see how to get it to work in vi at least. Just trying to be constructive! Not that it's relevant, but I've never actually encountered anyone who mixed tabs and spaces.. I've lived a sheltered life I guess. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs are *EVIL*, end of discussion. (Re: Tabs versus Spaces in Source Code)
Andy Sy wrote: >Don't be evil - always configure your editor to >convert tabs to true spaces. Yet another space-indenter demonstrates that problem actually lies with people who think that tab == some spaces. >And I, for the life of me, have never remembered >getting any source code to display properly by >fiddling with my text editor's (the very popular >SciTE) tab settings. Sorry to hear that. You should try using an editor that's easier for you. By the way, complaining about a thread's existence is pretty dumb. If you don't like it, don't post to it. Or are you unable to operate your news reader either? -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs versus Spaces in Source Code
>Hitting the spacebar like a madman? If you have a sensible editor then at >the start of a line you press tab once True! but normally if I'm editing someone else's code then I'm only making small changes and so can't be bothered to temporarily cripple my editor. If I'm merging my code with someone else's space-indented code then piping through sed 's/TAB/SPACES' does the trick. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs versus Spaces in Source Code
Jorge Godoy wrote >Emacs guess what's used in the file and allows me to use tabs all the time, >doing the correct thing... That sounds like useful behaviour. Maybe this is an area where modern editors might be able to save us from ourselves. I'll admit I'm suspicious of relying on editor functionality - I'm happier if I know I can also use the old-school methods just in case.. Sometimes adding intelligence to an interface can be a usability disaster if it makes wrong assumptions about what you want. But if people are hell-bent on converting tabs to spaces, maybe it's the best way to accommodate them. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs are *MISUNDERSTOOD*, *EVIL* AND *STUPID*, end of discussion. (Re: Tabs versus Spaces in Source Code)
Andy Sy >I guess this *REALLY* is how a misguided tab user exercises his 'logic': >Syntax replication (e.g. so-called 'argument construction') is enough, >semantics don't matter. That's quite amusing.. you've unwittingly stumbled on a pretty concise statement of Hilbert's first postulate of formal logic, proved by Godel in 1930.. >ROTFLMAO! Indeed. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs are EVIL *and* STUPID, end of discussion. (Re: Tabs versus Spaces in Source Code)
Andy Sy: >Code with anything other than 8-space tabs will *NEVER* display >properly using everyday unix utilities such as less and cat. less -x does what you want. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs are EVIL *and* STUPID, end of discussion. (Re: Tabs versus Spaces in Source Code)
Dave Hansen wrote: >That will work. As long as the creator of file used four-space TABs, >anyway... That sentence has no meaning. There is no such thing as a four-space tab. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs versus Spaces in Source Code ('semantic' vs. arbitrary indentation)
Andy Sy wrote:
>def sqlcall():
> cursor.execute('select id, item, amount, field4, field5, field6'+
> 'from table1 where amount>100')
Lines two and three (a continuation line) are both at a syntactic
indentation level of 1. Therefore they should both start with a tab.
(Though actually indentation is ignored for continuation lines so you
only need to preserve the indentation if you want alignment.)
Then you can add spaces to align the function arguments.
def sqlcall():
cursor.execute('select id, item, amount, field4, field5, field6'+
<---spaces>'from table1 where amount>100')
I prefer not to bother with alignment like this, but if you do want to
align things, you use spaces. Indenting is done with tabs; alignment
with spaces.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Tabs versus Spaces in Source Code ('semantic' vs. arbitrary indentation)
Dave Hansen wrote: >However, to twist an observation I've read about C++, while it's >clearly possible to use TABs in a sensible manner like this, it seems >that no one does. I think it's evident from this thread that quite a few people do that, judging by the fact that my previous post explaining this was doubly redundant by the time I got round to sending it. Also we should remember that in Python, alignment only applies to continuation lines and comments. Logical lines (the vast majority of lines in a source file) can't be arbitraily aligned. -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
It probably says something about your coding style, particularly in perl. I've found (anecdotally of course) that while perl is potentially the more economical language, writing *legible* perl takes a lot more space. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs versus Spaces in Source Code ('semantic' vs. arbitrary indentation)
Carl J. Van Arsdall wrote: > The converse can also be said, "it's difficult to make sure everyone > uses spaces and not tabs". > > I think we've just about beat this discussion to death... nice work > everyone! Yeah - we've got to the repeating ourselves stage. But that's the problem with this issue: it's really hard to get the space-indenters to actually think about it and to address what is being said. Every time it comes up, there's always a few people trying to explain why tabs give are a good idea, facing a whole raft of others spouting stuff like: 'mixing spaces and tabs is bad so use spaces only' 'tabs are x spaces and I like to use y spaces' 'tabs are bad end of story' and these non-arguments are repeated over and over within the same thread. At times it's like talking to a child - and not a bright one at that. Does it matter? Perhaps not if we can use tools which enable us to bridge the divide, like indent auto-detection in emacs and vim. I'm prepared to do that in cases where I have to work with an existing group of coders uasing spaces. But unfortunately the situation is worse than that: tab indentation needs to be actively defended. Most of the coding 'style guides' you'll find (including Python's) advocate spaces only. There are plenty of people who would like tabs removed from the language as an acceptable indentation method - look at the responses to Guido's April Fools blog entry last year. Unlikely perhaps. I hope so. It's a cruel irony that Python's creator didn't appreciate the benefits that tab indentation would bring to his own language - the only major language in which indentation levels actually have semantic significance. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs versus Spaces in Source Code ('semantic' vs. arbitrary indentation)
Edward Elliott wrote: > What really should happen is that every time an editor reads in source code, > the code is reformatted for display according to the user's settings. The > editor becomes a parser, breaking the code down into tokens and emitting it > in a personally preferred format. I completely agree, and I guess that is what I was groping towards in my remarks about using modern editing tools. At the same time I would be resist any move towards making source files less huiman-readable. There will still be times when those tools aren't available (e.g. for people working on embedded s/w or legacy systems), and that's when having ASCII source with tabbed indentation would be so useful. But it looks, sadly, like we're fighting a rearguard action on that one. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs are *MISUNDERSTOOD*, *EVIL* AND *STUPID*, end of discussion. (Re: Tabs versus Spaces in Source Code)
Duncan Booth wrote: > No. That is precisely the problem: there is code in the wild which > contains mixed space and tab indentation... > I wouldn't have a problem with tabs if Python rejected mixed indentation by > default, because then none of the code above would execute. I think it's great that at least we're all agreed that mixed indentation is a bad idea in any code, and particularly in Python. How would people feel about having the -t (or even -tt) behaviour become the default in future Python releases? A legacy option would obviously need to be provided for the old default behaviour. -- http://mail.python.org/mailman/listinfo/python-list
