Using the Python Interpreter as a Reference

[DevPlayer]

On Nov 29, 3:04 am, Steven D'Aprano <steve
+comp.lang.pyt... at 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... at 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;