Python and white space

Simon McAuliffe wrote:
> It's OK. But it is encumbered by one overriding and crippling original
> design decision: that code blocks should be decided purely by
> indentation. I originally considered Python for RepRap, but the
> indentation thing is so utterly dumb (just like tabs in Makefiles) that
> I voted against it.

I think this is one of the great things about Python. I agree make's use of tab is insane because it is an invisible character which gets modified by editors etc. Python uses indentation level to indicate blocks rather than curly braces or "begin ... end". This is fantastic for the following reasons: -

1. If it looks right then it is right, you don't have to search for hard to spot missing braces etc.

2. It saves screen lines so you can fit more code on the screen at a time making it easier to read.

3. It forces people to indent their code uniformly. With {} languages there are lots of different ways of indenting it and everybody has different preferences.

I use the original K&R style:
..if(something) {
.....do_something();
..}

More common but wastes a line is:
..if(something)
..{
.....do_something();
..}

Less waste but ugly:
..if(something)
..{ do_something();
..}

Insane:
..if(something)
.....{
.....do_something();
.....}

There are even more permutations, I always omit the braces when the block is a single statement but a lot of people don't. Hardly any two programmers like the same format and millions of man hours must be wasted by people reformating code to their prefered format so that they can read it and modify it. Then when you do a source control diff it looks like every line has changed.

In contrast, the only way to make a block in python is by positive indent, the only choice is by how much.

...if something:
.....do_something

Much easier to read, shorter, more like natural language, hard to get wrong, easy to see if it is wrong. When did you ever see an English paragraph denoted by braces or begin / end?

Granted you do need an editor where you can select a block of text and hit tab to indent it of shift tab to un-indent but that is common these days. Also you must not use tab characters as everybody sets up the their editor differently. It would have been better if Python rejected tabs in the source code. Commenting out code is a bit of a pain but apart from that I love it.

Other things going for it are it is very easy to learn and very productive. It also seems a lot easier to write portable code looking at the problems people are having with the Java host stuff. You don't need a complicated developement and build platform like Eclipse and Ant, or any fancy packaging. You just edit it with a text editor and run it, then zip it up and unzip it anywhere and run it.

Just my opinion but I have been writing software for 30 years now and I would always now use Python first choice, C++ then C then assembler, depending on how powerful the hardware was. I hear good things about Ruby from friends who's opinion I respect so I may learn that sometime.

PS.
The forum removes leading whitespace so I replaced it with dots.

Edited 2 time(s). Last edit at 06/21/2007 07:28PM by nophead.

---

[www.hydraraptor.blogspot.com]

That's a darned compelling endorsement!

I have also used Python a bit, and like it a lot. If I recall correctly, another nice thing about the indentation requirement is that it is variable - it doesn't matter if you use 2 spaces or 10 to indent - as long as you are consistent within that block of code, it is happy. Also, I have found Python wonderfully quick to debug (as interpreted languages generally are). You keep one window open with the source code in a text editor, and one window open with a command line - make a change in the source, hit Save, switch to the command line, and run the program. If ya make a typo, you just edit the text, hit Save, and try again.

I have also found that Python is a great learning language - I have found it relatively easy to follow what is going on in the source (and that source is generally in an easy-to-edit test file), so it presents less of a barrier for those who are not as experienced in programming to understand what is going on in the code.

That bit from Simon was actually quoting me, so I am the guilty party when it comes to dissing Python...

I like it for small interactive project development too, but I wouldn't dream of using it for a big software project for the reason I said. The point about how you lay out {} is a red herring: if you have the {} arranged any-old-how in your file then an automatic reformatter can prettify the whole thing any way you like and both the syntax and semantics are unchanged. This doesn't fix errors, but it often makes them obvious.

But if you have the indentation wrong in Python then no automatic power on Earth can help fix it; it can only be fixed by a very expensive human bean who understands the _semantics_ of the code and who would rather be down the pub...

And the idea that newline and whitespace characters should be syntactically significant in any piece of code smells like FORTRAN (what do _you_ put in column 6?), which is a bit like insisting that we write code enclosed in Egyptian cartouches...

---

best wishes

Adrian

[reprap.org]
[reprapltd.com]

There is no such thing as getting the indentation wrong in Python. The indentation defines the block structure. If it's wrong your block structure is wrong. It's plain to see so if it is wrong and you can't see it then it means your logic is wrong. Just like any other semantic error, it will take somebody time to fix but at least it is staring you / them in the face unlike things like :-

for(i = 0; i < 10; ++i);
....do_something(); // executed once!
do_something_else();

or

for(i = 0; i < 10; ++i)
....do_something(); // executed 10 times
....do_something_else(); // executed once!

or

for(i = 0; i < 10; ++i)
....do_something(), // executed 10 times
do_something_else(); // executed 10 times !

I am not sure if these all apply to Java. Alright, you can reformat it and you can lint it to help you see the problem but with Python you don't need to. The very existence of programs like cb and lint shows that {} languages are floored. These issues simply do not arise in Python.

As for not using it for large projects:

1) People do successfully, [groups.google.com]

2) I would not class the current RepRap code as a large project. It will grow with more heads, etc, but is a fairly well bounded problem of turning a 3D model into a sequence of machine commands. Compared to something like CAD, ECAD or even a word processor I would think it would be at least an order of magnitude smaller.
If you add something big like electronic component synthesis that would be better done as a separate program that does schematic to 3D geometry and feed that into RepRap rather than having one big program.

3) If it was written in Python it would be considerably smaller

If you are planning on it being a "large project" then you need to put in unit tests and use TDD or it will go the way large projects without these tend to go, i.e. brittle and hard to maintain.

Sorry if I am ranting but I just can't help it, 25 years of seeing badly formatted C has made me bitter and twisted!

---

[www.hydraraptor.blogspot.com]