On Nov 29, 3:04 am, Steven D'Aprano <steve +comp.lang.pyt...@pearwood.info> wrote: > On Tue, 29 Nov 2011 12:49:49 +1100, Chris Angelico wrote: > > On Tue, Nov 29, 2011 at 11:54 AM, DevPlayer <devpla...@gmail.com> wrote: > >> To me, I would think the interpreter finding the coder's intended > >> indent wouldn't be that hard. And just make the need for consistant > >> spaces or tabs irrevelent simply by reformatting the indent as > >> expected. Pretty much all my text editors can. > > > The trouble with having a language declaration that "a tab is equivalent > > to X spaces" is that there's no consensus as to what X should be. > > Historically X has always been 8, and quite a few programs still assume > > this. I personally like 4. Some keep things narrow with 2. You can even > > go 1 - a strict substitution of \t with \x20. Once you declare it in > > your language, you immediately break everyone who uses anything > > different. > > Why should we enforce how many spaces a tab is set to? That is literally > only visible to the editor, not the compiler. (Unless the parser is > particularly stupid and merely substitutes X spaces for a tab every time > it sees one.) > > Mixed spaces and tabs in an indent are ambiguous, and so raises > SyntaxError (or at least it *should* raise SyntaxError). But separate > code blocks can use different absolute indent levels without ambiguity, > so long as the relative indentation is consistent: > > def ham(): # tab stops at 4 and 8 > do(a) > do(b) > if c: > do(c) > else: > do(d) > > def spam(): # tab stops at 8 and 12 > do(a) > do(b) > if c: > do(c) > else: > do(d) > > There is no meaningful difference in indentation between ham and spam > above. In either case, I could replace spaces with tabs to get the same > relative indents regardless of the absolute indentation. > > I can appreciate the aesthetic argument that *within a single file*, > indentation should be consistent. But it's not logically necessary for > the parser: it need only be consistent within a single code unit > (function or class usually). In other words: syntax should only care > about relative indentation, absolute indentation belongs as a coding > standard. > > -- > Steven
Great point. Your point is why I started writting my own little Python parser/scanner (as an pet project/lesson project) and is in part, why I wrote my little reindent() in the first place. I am/was trying to figure out the algorithim for how Python's indent/dedents made logical "code blocks" or "closures" or whatever they are called. That and see if there was a way to interpret docstrings in various formats. I often get indentation syntax errors when I cut and paste stackflow.com, devprogrammer.com, daniweb.com, etc. code snippets into my various IDEs/ editors and I wanted to make a little tabnanny of my own. Some of the IDEs and editors (Editra) allow plugins. So I wanted to get a baseline for the various plugins. So I call the reindent() after I call the blocker(), which determines a block by -releative- indent/dedent as +1 or, 0 or -1 whether that be +4 spaces, +2 spaces, +1 tab or -3 spaces, whatever...; as you, Steve, mentioned indent is not fixed but relative. (btw I'v posted this in this topic because I thought it could contribute to how Unit's choice of how indents are handled my benefit from this discussion). My thoughts on tab verse space chars;, for most old and even current commandline interfaces, text editors, and historically line printers, tabs simply acted like a macro to move x number of fixed spaces. It wasn't until varible width fonts, kerning, and other advanced printing techniques became mainstream<- did space chars differ in meaning from tab chars, exception perhaps being file storage space (way back in the day). I only say this because I can't stand hitting the right and left arrow keys or using multiple fingers to move left and right 3 more times then I have to while editing my text. I -feel- I move faster around my text files with tabs then I do with 4 spaces. They only annoyance I've had with Python's flexiblity with indent using tab and or spaces is the docstrings. \t = tab def myfunc(): \t"""here is my docstring that bla bla bla's \t\tand indented do da days... \t""" verse (s = space) def myfunc(): ssss"""here is my docstring that bla bla bla's ssssssssand indented do da days... ssss""" verse space = tab or space def myfunc(): "here is my docstring that bla bla bla's"\ " and indented do da days..."\ "\n" verse the legal and sometimes seen form: def myfunc(): \tmyval = somefunc( arg0, arg1, arg2, lotsofargs, \t\tsssspaces_to_align_arg_to_arg0) If you strip the text and display it using basic reformatting in fixed font, like in the python interpreter, no biggy. But when you want to display the docstrings in an advanced font, like that of an ide with truetype fonts, formatting gets lost without having the app account for all the various ways Python coders do their docstrings. So if you wanted a consistant flexible (really) long term way to autogenerate and publish your and others code/packages/libraries, it gets tricky. Ask big-python-library maintainers know, many people go to chat and forums simply because autogenerated documention wasn't clear to the non-expert, thus repeating the same questions over and over. AND perhaps in the beginning it was well documented but since new constructs and refactoring of code, often auto-generated documentation can get "reduced" to something unuseful to those not-in- the-know. If whitespace indentation is used to define some construct of a programming language, then how people like to document their code (by using various forms of whitespace) could impact how well -some- people learn the new language. Auto-generated documention could very well be influenced by that decision. What form of whitespace indentation could effect readability/ understandable code. For example reducing indentation to 2 spaces instead of 4 might encourage some coders to use even deeper indentation because the code could fix more stuff (it's not being used up by whitespace indentation). Many feel that's a bad thing (I do too). (not knowing Unit code; I'll use Python) class Wow(object): def myfunc(self): a = func() if a: small_indent = something() if small_indent: getting_silly = godeeper() while getting_silly > a: bet_you_get_the_point += getting_silly - code_makes_no_sense() for i in range(100: if bet_you_get_the_point in SOMEGLOBAL['part1'][0]: display(a, small_indent, getting_silly, bet_you_get_the_point) Well, that may be a little hyperbolic. But with 2 spaces you can encourage coders to get very deep, indentially, and still fit 80 chars. (newly invented word: indentially. But I don't care, you get the point.) To me, each viewer of that code should be able to put the indent to something that fits their taste. And lets face it. most source code today is viewed in some gui text editor that can reinterpret that indent to whatever, without generating interperter indentation errors later. The only exception to consistancy would again be docstrings or more precisely string blocks, or block strings, or tripe quoted, whatever you want to call them. My words are not meant to garner flames or anything, just to cause thought; -- http://mail.python.org/mailman/listinfo/python-list