Softpanorama

May the source be with you, but remember the KISS principle ;-)
Home Switchboard Unix Administration Red Hat TCP/IP Networks Neoliberalism Toxic Managers
(slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and  bastardization of classic Unix

Great Python Indentation Debate

News Scripting Languages

Best Python books for system administrators

Recommended Links Python Braces Debate Command-Line Syntax and Options Python pretty printers
Beautifiers and Pretty Printers Python Debugging Python source code checking tools to help you find common bugs pdb — The Python Debugger Programming environment Python IDEs Pycharm IDE
Python for Perl programmers   Quotes Python history Tips Etc  

Introduction

 

Many discard Python because it uses indentation to denote nested blocks and non a familiar C-like syntax based od curvy braces or Algol-68 syntax (that survived only in Unix shell with its famous if -fi pair) . I think that's a big mistake.

Indentation is not a burden because the most natural form of the program is an indented one. In languages like PL/1, C  a pretty printer is a must. But if you consistently uses a pretty printer why waist two useful symbols ("{" "}" ) for what can be done with comments.  That means that indentation can be always generated automatically from special comments. But the problem is that it is optional feature, you don't have to use it, but it is highly recommended. You should  use pseudo-comments like and "#} if " or " #} while"  to increase the readability of the program. Especially if Python is not the only language in which you program.

Such a tool comes with the standard python distribution (look for pindent in the Tools directory cpython-pindent.py at master · python-cpython · GitHub).

# This file contains a class and a main program that perform three
# related (though complimentary) formatting operations on Python
# programs.  When called as "pindent -c", it takes a valid Python
# program as input and outputs a version augmented with block-closing
# comments.  When called as "pindent -d", it assumes its input is a
# Python program with block-closing comments and outputs a commentless
# version.   When called as "pindent -r" it assumes its input is a
# Python program with block-closing comments but with its indentation
# messed up, and outputs a properly indented version.

# A "block-closing comment" is a comment of the form '# end '
# where  is the keyword that opened the block.  If the
# opening keyword is 'def' or 'class', the function or class name may
# be repeated in the block-closing comment as well.  Here is an
# example of a program fully augmented with block-closing comments:

# def foobar(a, b):
#    if a == b:
#        a = a+1
#    elif a < b:
#        b = b-1
#        if b > a: a = a-1
#        # end if
#    else:
#        print 'oops!'
#    # end if
# # end def foobar

# Note that only the last part of an if...elif...else... block needs a
# block-closing comment; the same is true for other compound
# statements (e.g. try...except).  Also note that "short-form" blocks
# like the second 'if' in the example must be closed as well;
# otherwise the 'else' in the example would be ambiguous (remember
# that indentation is not significant when interpreting block-closing
# comments).

In essence Python requires usage GUI-based  python-aware editor...

In other words in Python adding block-delimiting comments is the optional feature and the use of whitespace is the mandatory feature. Python reversed the priority because whitespace is a better visual aid in understanding the flow of a program. But if you use comments to mark beginning and end of each block and automatic indentation, than it's indentation than really matters. And that's great. It's easy to miss delimiters like "{" and "}" when looking over one screenpage of code. So for beginners who do not write large scripts this is a blessing, but for seasoned programmers it quickly became a nuisance with the growth the size of code. You can argue that you should keep you modules reasonably small and it is a good argument, but life is more complex that that.

The problem with indentation is that if block is long it is visually lost, as you do not see on the screen where the block starts. Folding in such cases might help.  So working with large scripting in Python presuppose using pretty advanced editor and folding capabilities. Which might be a good thing, as I hate programmers who use nano ;-) 

Languages such as Perl and Tcl made their design decisions based on familiarity with C rather than usability. They simply borrowed the successful C-based notation of using curly braces for blocks (which actually is "one one step forward, two steps back" from PL/1 notation, which served as prototype for C, as PL/1 allows to close multiple blocks using labels and C does not ). C misses some earlier PL/1 extensions like closing several blocks with one delimiter. In Python one get this nice feature for free.

Using white space for indentation creates tricky to debug errors for beginners as they can mix tabs and spaces in the same program and the resulting indentation now depends on congruence of tab setting in Python interpreter and the editor. If the settings are different  on different servers (and they often are) users are in deep trouble and resulting diagnostics is pretty weak, if not to say horrible (Python interpreter should accept iether "tab indented" code or "space indented", but in case both are used it should produce an error, or at least a warning).

Cut and paste Python code from Web is tricky

ABC designers from which Python borrowed this feature decided to imitate FORTRAN 4 to use an indentation to a part of syntax -- this time to denote nesting. Which is not that different from  the way Fortran 4 used it to distinguish between labels and statements ;-).

As the result Python is a language that, in the age of the ubiquitous HTML-driven web, cannot be cut and pasted from the Web page into an editor and executed successfully, if there is any indention/code grouping at all. Certainly a "bold" design decision.

Copy and paste this code:

if foo:
x = y+foo
if x > 4:
foo =3

Was the original block formatted like?

if foo:
    x = y+foo
if x > 4:
    foo =3

OR?

if foo:
    x = y+foo
    if x > 4:
       foo =3

What happens if the editor 'helpfully' fixes things to one of those 2 choices? and it picks the wrong formatting. A big enough block of code, enough of a hurry and it will not be caught.

That creates problems  if tabs are used. In this case you often have the case when your source has mixture of tabs and leading spaces. Different editors have different default setting for tabs and this way your nesting can became incorrect without you knowing it. Python interpreter has an option to warn you about this situation but you need to use it to get the warnings.

Using nesting as syntax element creates problems with diffs 

The typical way to do diffs in for source code is first to eliminates leading blanks. This does not work well for Python ;-)  Also complering fragment became more tircky if those two fragment of code exist on different nesting levels.

Another side effect that if you want to write statement on level of nesting equal to zero you can't  put any leading spaces before. Python forces you to  start at column one. Which for me is pretty annoying. Of course there are way around this limitation (you can always put statements into a subroutine, and that's how Python programs are usually structured with main being  yet another subroutine) , but  still this is a drawback.

By relegating block brackets to the lexical level of blank space and comments Python failed to make a necessary adjustment and include pretty printer into interpreter (with the possibility of creating pretty printed program from pseudo-comments like #fi #while, etc ). Such a pretty printer actually is  needed to understand larger Python programs: format of comments can be Algol-68 style (or Bash style if you wish for people who never heard of Algol-68; that's the only feature that Borne shell inherited from algol-68 and Bourne was a member of Algol-68 development team before writing this program ;-). For example:

if a > b :
   delta=b-a
#fi

and the current number of spaces in the tab like  pragma tab = 4. The interesting possibility is that in pretty printed program those comments can be removed and after a reading pretty printed program into the editor reinstated automatically. Such feature can be implemented in any scriptable editor.

My impression is that few people understand that C  solution for blocks ({ } blocks) was pretty weak in comparison with its prototype language (PL/1): it does not permit nice labeled closer of blocks like

A1:do 
   ... 
end A1; 

in PL/1. IMHO introduction of a pretty printer as a standard feature of both a compiler and a GUI environment is long overdue.

But there is silver lining in each dark cloud: by adding indentation as the proxy for nesting Python actually encourages a programmer to use a decent editor (which mean not nano/notepad family ;-), but we knew that already, right? 

Theoretically this design decision also  narrows down the possible range of coding styles and  automatically leads to more compact (as for the number of lexical tokens) programs (deletion of curly brackets usually help to lessen the number of lines in C or Perl program by 20% or more).  But in practice Python programs tend to be  more verbose then Perl due to abuse of modularization and OO.

Forced converted of tabs into spaces is a "must"

Mixing tabs and space are invitation to disaster. Which simply means that tabs should never be  use while writing Python code.

 This "gotcha" is often missed in Python introductory books. Explanation in python.org is primitive and missed this gotcha:

Why separate sections by indentation instead of by brackets or 'end' - Python Wiki

SEE:Ten things people want to know about Python

Answer
  • In order to separate blocks of code (like for loops, if blocks and function definitions) the compiler / interpreter needs something to tell it when a block ends. Curly braces and end statements are perfectly valid ways of providing this information for the compiler. For a human to be able to read the code indentation is a much better way of providing the visual cues about block structure. As indentation also contains all the information for the compiler, to use both would be redundant. As indentation is better for humans, it makes sense to use that for the compiler too. It has the advantage that Python programs tend to be uniformly and consistently indented, removing one hurdle to understanding other people's code. Python does not mandate how you indent (two spaces or four, tabs or spaces - but not both), just that you do it consistently. Those that get used to the Python way of doing things tend to start seeing curly braces as unnecessary line noise that clutters code. On the other hand, 'the whitespace thing' is possibly the single biggest reason why some developers refuse to even try Python.

[Folklore says that the ABCers in the '80s experimentally determined that significant whitespace has measurable advantages. 'Anyone have documentation for this?]

Additional observation::

 

Unforced errors: God help you if you added an if-branch in the middle of that existing if-branch.

Also using whitespace for indentation creates some "unforced errors" :

A summary of an interesting Slashdot discussion

See an interesting Slashdot discussion below that shed some additional light on the situation.

Re:Python - so close... (Score:2, Insightful)
by JohnPM on Sunday April 23, @12:48PM EST (#84) (User Info)
... syntactic indenting ...  narrows down the possible range of coding styles. If you think about it, most of the (dare I say) splintering of C/C++/Java coding styles is due to the placement of the { and } symbols. This acts against readability for other developers. It's also less typing.

If you like the keybindings and programmability of Emacs, but don't like its size, try JED which also has a pretty good Python mode, too.

...and yet grounded in its 1950's roots?? Idea! (Score:3, Interesting)
by devphil on Sunday April 23, @12:35PM EST (#79) (User Info)
That's something that seriously bugs me about Python.

...the required indentation just stupifies me. I feel like I'm writing a FORTRAN 77 program, indenting to the correct place so that the compiler/interpreter can find the right column of the punched card...

I'm not a big fan of 1950's cars, clothes, music, or programming languages.

A really useful tool (written in Python or Perl or awk or whatever) would read in a "Braced Python" file, remove the {}'s and redo the indentation inside them, and then write out a syntactically-correct file. (For bonus points, play some 50's tunes while it's converting.)

This would aid the transition from free-form languages like C++ (and FORTRAN 95...). It's enough to introduce new ideas; don't beat the user over the head with personal indentation preferences at the same time.

Re:...and yet grounded in its 1950's roots?? Idea! (Score:4, Insightful)
by eff on Sunday April 23, @01:21PM EST (#88)  (User Info) http://www.pythonware.com/people/fredrik
A really useful tool (written in Python or Perl or awk or whatever) would read in a "Braced Python" file, remove the {}'s and redo the indentation inside them, and then write out a syntactically-correct file.

such a tool comes with the standard python distribution (look for pindent in the Tools directory).

(there's also something called corbascript, which is pretty much python with braces...)

Real python programmers tend to use python-aware editors, but that's another story...

Re:Python - so close... (Score:1)
by mcdonc ([email protected]) on Sunday April 23, @11:53PM EST (#122)
(User Info) < a target="_blank" href="http://www.digicool.com">http://www.digicool.com
That's completely false. Perl certainly has strong OO syntax. Perl, in fact, has much stronger OO than Python. A couple of reasons are that in Perl you have privacy, and also because in Perl its much easier to generate metaclasses.

I write python all day long every day. I used to do same for perl. This statement is pretty darn funny. As my coworker jeffrey (with a derisive snort) would say "OO is all about virtual private methods and late bindings" (then bust up laughing).

Re:Python....watch out...(maybe) (Score:2, Informative)
by TresEquis on Sunday April 23, @09:33PM EST (#117)
(User Info) http://www.palladion.com

From what I can tell, they plan on revamping pretty much all of the syntax...and it won't be backwards compatible in the end release.(they do plan on working slowly up to it, AFIAK)

Nyet, tovarisch. The "backwards compatibility" issue in Python 3000 is mostly likely to bite extension writers, who code to Python's C API; most code written in Python will see very little, if any, compatibility problems.

I don't recall any of the specifics, but maybe they will be integrating the most sought after change....no more tabs and whitespace! ;)

No way, no how, not ever! The use of indentation to indicate block structure is a core feature, there by explicit design, to increase readability (you probably indent your C/C++, Java, or Perl to match the block structure already, right? so just lose the "noise" characters, and let the parser read the indentation).

The issue has been repeatedly raised on comp.lang.python, mostly by people who haven't actually used Python for anything significant. As for the dreaded whitespace-eating nanoviruses, those have been discussed extensively on the newsgroup, as well.

Re:Python....watch out...(maybe) (Score:1)
by soulhuntre on Monday April 24, @12:49AM EST (#127)
(User Info) http://www.virtualchemy.com
"...so just lose the "noise" characters..."

Sorry, but no. This is simply too much for a number of reasons...
  1. positionally dependant languages are simply silly.
  2. my programmers work in Perl and C++ as well, there is no reason to inflict a radically different syntax system on them
  3. for those of us with long programming histories, those {} characters are important visual cues in the code we read, I have no intention of turning off reflexes I learned over the last 20 years or so just to satisfy someone's syntax egotism.

Ken

Re:Python....watch out...(maybe) (Score:1)
by CoderDevo on Monday April 24, @04:57AM EST (#130)
(User Info)
Your argument falls apart when you realize that Python is designed to be a language that is for newbies, is for oldies, is here to stay and will create careers for Python programmers.

Answers:

1) positionally dependant languages are simply silly.

No paradigm is "simply silly." It either works, or it doesn't. In the context of Python, positional dependence helps define the language. Have you ever taken over someone elses code? This enforces easy to read, easy to maintain code.

2) my programmers work in perl and C++ as well, there is no reason to inflict a radically different syntax system on them

Not much faith in your programmers. I see that if they know Perl well, then there may be no need to use Python. However, I was given the choice of learning a modern scripting language. I already knew Borne shell and awk. After much research, I decided on Python. My C++ is strong and Python was an obvious fit for my skills and style. I am still happy with the decision.

3) for those of us with long programming histories, those {} characters are important visual cues in the code we read, I have no intention of turning off reflexes I learned over the last 20 years or so just to satisfy someones syntax egotism.

These "visual cues" are learned. Just as positional dependence is learned. It's just a different paradigm, not necessarily better or worse.(better) :)


Top Visited
Switchboard
Latest
Past week
Past month

Old News ;-)

[Nov 06, 2017] Indentation Error in Python - Stack Overflow

[Nov 06, 2017] Python Myths about Indentation

[Jun 26, 2002] Which is better, python or perl And more importantly, why

Kragen Sitaker [email protected]
Wed, 26 Jun 2002 04:19:08 -0400 (EDT)

This kragen-tol article was published (with some of the mistakes removed) in ;login: this month; I had the following interesting conversation with a reader, which I repost here with his permission.

Date: Thu, 13 Jun 2002 14:32:50 -0700 (PDT)
From: "Simon J. Gerraty" <[email protected]>
Subject: Re: python indent sensitive

Hi,

I was reading your article in ;Login: regarding python cf. perl. In your comments about python being indentation sensitive you assert that anyone who finds this silly is an unthinking moron.

I recall looking at the python web pages some years ago - since python sounded cool, and saw a claim that "there is a very good reason python doesn't use braces", but that reason was never given.

Since you clearly hold that python's indentation sensitivity is a bonus, perhaps you could explain why - with actual reasons that is.

Its possible I'm wrong to think that python would have been a very good language if only it used braces for grouping rather than indentation, but absent something a bit more convincing than "its better", I can only imagine it being a source of hard to track bugs.

Thanks --sjg

Date: Thu, 13 Jun 2002 18:52:15 -0400
From: Kragen Sitaker <[email protected]>
Subject: Re: python indent sensitive
Simon J. Gerraty writes:
> I was reading your article in ;Login: regarding python cf. perl.
> In your comments about python being indentation sensitive you
> assert  that anyone who finds this silly is an unthinking moron.

I haven't seen the printed version yet, but I think I said that certain kinds of "unthinking morons" (your words, not mine) didn't like it, but I specifically said there might be reasons other than being an "unthinking moron" that one might not like it.

Many people who "unthinkingly adhere to stupid traditions" (my words from the article) are quite intelligent.

> Since you clearly hold that python's indentation sensitivity is a
> bonus, perhaps you could explain why - with actual reasons that
> is. 

With braces, I have to say what I mean twice --- once with the braces, so the compiler can understand me, and once with indentation, so humans can understand me. If I get it wrong, I have an unseen bug. As a C, C++, and Perl programmer, I eventually developed very sharp eyes for things like this:

if (foo)
   debug_printf("foo happened\n");
   barf();
do_something_else();
In Python, I don't have to waste my attention on that any more.

Whitespace is a preattentive feature; it is processed by my retina and visual cortex without any conscious attention on my part and very little effort, and I can see *all* of the whitespace in a large visual display in less than a quarter of a second, about the time it takes my eye to move from one spot to another. It is a major benefit to be able to understand the nesting structure of a whole screen or page of source code automatically and with no effort. That is why indentation to show nesting in source code is universal today.

Python simply removes the possibility that your subconscious, preattentive understanding of your program's structure is incorrect. Knowing that a program is written in Python also eliminates the possibility that it is unindented; an unindented C program can be run through 'indent', but an unindented Perl program is a nightmare.

People occasionally suggest that this lack of redundancy will lead to bugs, as a misindented statement won't be noticed later. (Specifically, a statement that should be inside a block being after the block, or vice versa.) I've introduced lots of bugs in programs, and I have kept exhaustive records of the bugs I found in many small programs. I cannot recall any bugs of this nature in my Python or Perl programs, but I have introduced this kind of bug a few times in C and C++ programs, usually in the way shown above.

It is rarely subtle in its effects, but it is often hard to find.

I don't argue that redundancy is always bad, but that in this particular case, the redundancy proves not to be worth its price.

For my thoughts on when redundancy in syntax (and programming languages in general) is a good idea, see http://lists.canonical.org/pipermail/kragen-tol/2002-April/000705.html "Lisp syntax considered insufficiently redundant" and http://www.paulgraham.com/redund.html "Redundancy and Power".


Subject: Re: python indent sensitive
Date: Thu, 13 Jun 2002 17:44:08 -0700
From: "Simon J. Gerraty" <[email protected]>
Hi, I dropped the login address [the original mail was Cc:ed to [email protected]] - since it was wrong anyway :-)
> > Since you clearly hold that python's indentation sensitivity is a
> > bonus, perhaps you could explain why - with actual reasons that
> > is.  
> 
> With braces, I have to say what I mean twice --- once with the braces,
> so the compiler can understand me, and once with indentation, so humans
> can understand me.  If I get it wrong, I have an unseen bug.  As a C,

Hmmm, interesting. I'm thinking more of the case where I put the braces in and the editor does the indenting for me - emacs, no pain at all.

Further, while indentation alone may suffice for a screen's worth of code, I find it inadequate for grossly large blocks of code. Note that I often have to debug programs written by others so the fact that a huge function should be re-organized is orthogonal to understanding what it is doing. Being able to ask a tool like an editor "go show me where this block started" is very handy. Matching braces etc makes this easy.

Now of course it could be the case that there is a decent python mode for emacs that handles all this.

> code automatically and with no effort.  That is why indentation to show
> nesting in source code is universal today.

Sure, but using braces makes it simpler to write tools to munge/analize code. Does python treat a line of code indented with a TAB differently to code indented with spaces?
> it is unindented; an unindented C program can be run through 'indent',
> but an unindented Perl program is a nightmare.

Yep, any unindented code is a nightmare.

> People occasionally suggest that this lack of redundancy will lead to
> bugs, as a misindented statement won't be noticed later.  (Specifically,
> a statement that should be inside a block being after the block, or
> vice versa.)  I've introduced lots of bugs in programs, and I have
> kept exhaustive records of the bugs I found in many small programs.
> I cannot recall any bugs of this nature in my Python or Perl programs,
> but I have introduced this kind of bug a few times in C and C++ programs,
> usually in the way shown above. 

Again, I'm more concerned about code I didn't write. Anything that assists me in analyzing the code for bugs is good.

Anyway, thanks for elaborating on "its better".

--sjg

From: [email protected] (Kragen Sitaker)
Date: Wed, 19 Jun 2002 15:43:00 -0400  (I think)
Subject: Re: python indent sensitive
You write:
> Hmmm, interesting.  I'm thinking more of the case where I put the
> braces in and the editor does the indenting for me - emacs, no pain at
> all.

Well, when you're *writing* code --- typing it out one line after another --- it's usually not a problem, with or without braces. It's when you're *editing* code that the problem comes up. In Emacs, at least, I experience some pain when you're creating or deleting blocks around existing code; sometimes I revert to C-n TAB C-n TAB, but there is of course M-C-\, which requires me to select the affected code first, after having already added or deleted braces. In Python, I typically select the affected code and hit C-c > or C-c <.

I should record an editing session sometime to identify the particular transformations I'm really performing instead of the ones that come to mind.

When you're *reading* code, the braces just take up space without conveying any information not already conveyed by the whitespace.

> Further, while indentation alone may suffice for a screen's worth of
> code, I find it inadequate for grossly large blocks of code.

Meaning that you need both block structure and editor support for it?

> Note that I often have to debug programs written by others so the
> fact that a huge function should be re-organized is orthogonal to
> understanding what it is doing.  Being able to ask a tool like an
> editor "go show me where this block started" is very handy.
> Matching braces etc makes this easy.

Well, unfortunately forward-sexp and backward-sexp don't think Python blocks are sexps, but when I want to know where a block began, I usually move to the end, hit Enter, then hit Backspace a few times. Each Backspace moves me back one indent level (like } in C-mode with auto-mode turned on) and prints a line in the minibuffer telling me where the block I'm closing began. This isn't ideal, but it's usually good enough.

Someone has hacked up an outline minor-mode for Python thet lets you collapse functions and classes; I wish I had something like that for arbitrary blocks.

> Sure, but using braces makes it simpler to write tools to
> munge/analize code.   Does python treat a line of code indented with
> a TAB differently to code indented with spaces?

It treats it as if it had been run through 'expand -8'.

I often find indentation more useful for writing automated tools, too; questions like the following are easier to answer by indentation than by parsing. (They all can get fouled up by Python's multiline strings, though, because those can be arbitrarily indented or outdented.)

You can do shallow processing like this correctly without parsing the code (just tokenizing it) if you have indentation to help you.

I originally posted the comparison article to a mailing list of my own; would you mind if I forwarded this conversation about it to the list too?

Subject: Re: python indent sensitive
Date: Wed, 19 Jun 2002 15:54:08 -0700
From: "Simon J. Gerraty" <[email protected]>
> > Further, while indentation alone may suffice for a screen's worth of
> > code, I find it inadequate for grossly large blocks of code.
> 
> Meaning that you need both block structure and editor support for it?
Not sure I follow.
> > Note that I often have to debug programs written by others so the
> > fact that a huge function should be re-organized is orthogonal to
> > understanding what it is doing.  Being able to ask a tool like an
> > editor "go show me where this block started" is very handy.
> > Matching braces etc makes this easy.
> 
> Well, unfortunately forward-sexp and backward-sexp don't think Python
> blocks are sexps, but when I want to know where a block began, I

I guess that's my point. A little ginger bread like braces would make python look a bit more like other langs that emacs groks well.

> I originally posted the comparison article to a mailing list of my
> own; would you mind if I forwarded this conversation about it to the
> list too?

Sure, no problem.

--sjg

-- <http://www.pobox.com/~kragen/>

A good conversation and even lengthy and heated conversations are probably some of the most important pointful things I can think of. They are the antithesis of pointlessness!

-- Matt O'Connor <[email protected]>

Braces Problem

A really useful tool (written in Python or Perl or awk or whatever) would read in a "Braced Python" file, remove the {}'s and redo the indentation inside them, and then write out a syntactically-correct file. such a tool comes with the standard python distribution (look for pindent in the Tools directory).
Re:Python - so close... (Score:2, Insightful)
by JohnPM on Sunday April 23, @12:48PM EST (#84) (User Info)
The syntactic indenting in Python is actually extremely cool. Ok, so maybe it means that emacs is the only editor it makes sense programming with - but we knew that already right? The main benifit I see to syntactic indenting is that is narrows down the possible range of coding styles. If you think about it, most of the (dare I say) splintering of C/C++/Java coding styles is due to the placement of the { and } symbols. This acts against readability for other developers. It's also less typing.

If you like the keybindings and programmability of Emacs, but don't like its size, try JED which also has a pretty good Python mode, too.

...and yet grounded in its 1950's roots?? Idea! (Score:3, Interesting)
by devphil on Sunday April 23, @12:35PM EST (#79) (User Info)
That's something that seriously bugs me about Python. I have tried over the years to not be a syntax bigot, but Perl loses in this respect. I saw the quip, "Perl -- the only programming language that looks the same both before and after RSA encryption," and it makes perfect sense.

Dilbert's joke about a rat dancing on his keyboard and writing a web browser could probably come true in Perl.

Python is a big, big win. But the required indentation just stupifies me. I feel like I'm writing a FORTRAN 77 program, indenting to the correct place so that the compiler/interpreter can find the right column of the punched card...

I'm not a big fan of 1950's cars, clothes, music, or programming languages.

A really useful tool (written in Python or Perl or awk or whatever) would read in a "Braced Python" file, remove the {}'s and redo the indentation inside them, and then write out a syntactically-correct file. (For bonus points, play some 50's tunes while it's converting.)

This would aid the transition from free-form languages like C++ (and FORTRAN 95...). It's enough to introduce new ideas; don't beat the user over the head with personal indentation preferences at the same time.

Re:...and yet grounded in its 1950's roots?? Idea! (Score:4, Insightful)
by eff on Sunday April 23, @01:21PM EST (#88) (User Info) http://www.pythonware.com/people/fredrik
A really useful tool (written in Python or Perl or awk or whatever) would read in a "Braced Python" file, remove the {}'s and redo the indentation inside them, and then write out a syntactically-correct file.

such a tool comes with the standard python distribution (look for pindent in the Tools directory).

(there's also something called corbascript, which is pretty much python with braces...)

real python programmers tend to use python-aware editors, but that's another story...

Re:Python - so close... (Score:1)
by mcdonc ([email protected]) on Sunday April 23, @11:53PM EST (#122)
(User Info) http://www.digicool.com
That's completely false. Perl certainly has strong OO syntax. Perl, in fact, has much stronger OO than Python. A couple of reasons are that in Perl you have privacy, and also because in Perl its much easier to generate metaclasses.

I write python all day long every day. I used to do same for perl. This statement is pretty darn funny. As my coworker jeffrey (with a derisive snort) would say "OO is all about virtual private methods and late bindings" (then bust up laughing).

Re:Python....watch out...(maybe) (Score:2, Informative)
by TresEquis on Sunday April 23, @09:33PM EST (#117)
(User Info) http://www.palladion.com

From what I can tell, they plan on revamping pretty much all of the syntax...and it won't be backwards compatible in the end release.(they do plan on working slowly up to it, AFIAK)

Nyet, tovarisch. The "backwards compatibility" issue in Python 3000 is mostly likely to bite extension writers, who code to Python's C API; most code written in Python will see very little, if any, compatibility problems.

I don't recall any of the specifics, but maybe they will be integrating the most sought after change....no more tabs and whitespace! ;)

No way, no how, not ever! The use of indentation to indicate block structure is a core feature, there by explicit design, to increase readability (you probably indent your C/C++, Java, or Perl to match the block structure already, right? so just lose the "noise" characters, and let the parser read the indentation). The issue has been repeatedly raised on comp.lang.python, mostly by people who haven't actually used Python for anything significant. As for the dreaded whitespace-eating nanoviruses, those have been discussed extensively on the newsgroup, as well.

Re:Python....watch out...(maybe) (Score:1)
by soulhuntre on Monday April 24, @12:49AM EST (#127)
(User Info) http://www.virtualchemy.com
"...so just lose the "noise" characters..."

Sorry, but no. This is simply too much for a number of reasons...
  1. positionally dependant languages are simply silly.
  2. my programmers work in perl and C++ as well, there is no reason to inflict a radically different syntax system on them
  3. for those of us with long programming histories, those {} characters are important visual cues in the code we read, I have no intention of turning off reflexes I learned over the last 20 years or so just to satisfy someones syntax egotism.

Ken

Re:Python....watch out...(maybe) (Score:1)
by CoderDevo on Monday April 24, @04:57AM EST (#130)
(User Info)
Your argument falls apart when you realize that Python is designed to be a language that is for newbies, is for oldies, is here to stay and will create careers for Python programmers.

Answers:

1) positionally dependant languages are simply silly.

No paradigm is "simply silly." It either works, or it doesn't. In the context of Python, positional dependence helps define the language. Have you ever taken over someone elses code? This enforces easy to read, easy to maintain code.

2) my programmers work in perl and C++ as well, there is no reason to inflict a radically different syntax system on them

Not much faith in your programmers. I see that if they know Perl well, then there may be no need to use Python. However, I was given the choice of learning a modern scripting language. I already knew Borne shell and awk. After much research, I decided on Python. My C++ is strong and Python was an obvious fit for my skills and style. I am still happy with the decision.

3) for those of us with long programming histories, those {} characters are important visual cues in the code we read, I have no intention of turning off reflexes I learned over the last 20 years or so just to satisfy someones syntax egotism.

These "visual cues" are learned. Just as positional dependence is learned. It's just a different paradigm, not necessarily better or worse.(better) :)

Recommended Links

Google matched content

Softpanorama Recommended

Top articles

Sites

In praise of mandatory indentation for novice programmers programming

cpython-pindent.py at master · python-cpython · GitHub



Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotesSomerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose BierceBernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-MonthHow to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D


Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to to buy a cup of coffee for authors of this site

Disclaimer:

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: November, 20, 2019