Allowing Arbitrary Indentation in Python

[Gary]

Hi! I'd like to join the fray, as the person who posted that original
LJ rant. First, some full disclosure, and stampings out of what seem
to me to be misconceptions...

1) I am not a CS major. I majored in Computer Animation at an art
college. I'm quite well aware that I don't know all there is to know
about scripting, let alone programming. I've always been rather
technically minded, and many have wondered why I didn't just go the CS
route, but I think I'm too much of a hippy artsy type for it.
2) I started in gw basic, and Qbasic, in '92, but have also used a bit
of C++, x86 Assembly, PIC Assembly (PIC Microchips), many BASICs for
software and hardware (e.g. DarkBASIC, PBasic (Parallax BASIC Stamps),
TI BASIC for calculators, etc), lots of Perl for several years,
Actionscript/Javascript, a bit of Java, of course many of the web
languages, some bash script, pretty much anything that exposes some
scripting tools to me, and have even toyed lightly in Lisp, and am
curious about Haskell. I'm certainly no expert programmer, but I've
been around the block, and at least know a bit of, and about what's
out there.
3) I'm not at all married to anything. I've been on 4 different
Windows since '92, and used Macs between '95-'99, but switched
entirely (at home) to Linux over a year ago. I've since mostly given
up on GUI text editors, preferring the sleekness of Vim, and the power
of work in the shell. Now that Python is available to me in Maya, I'm
VERY interested in leaving MEL behind :) Clearly, I'm capable of
change, and even do so rather willingly at times.
4) I know deep down that you may all be right, and that I could even
be completely insane, making any of my thoughts the irrational
mumblings of a crazed man, but in order to accomplish anything, like
getting out of bed in the morning, I must at least believe I am
capable of rational thought, learning, and self-improvement. As an
example, I believe this point #4 to be at least a somewhat rational
set of statements.

Grant Edwards said:
"Code should work the way it looks and look the way it works."

I fully agree. To that end, the MEL UI code I write does look exactly
like how it works to me. To me, the layouts are a stack of a
containers, which can be thought of in 3D like this (example found
online):

http://homepages.inf.ed.ac.uk/group/slip0506_a/shen/img/gui_layout.jpg

...which look quite like indented blocks in that view, with siblings
indented the same amount beyond their parent. Here's the thing that
really gets me, though about everyone's total consternation here: What
I'm doing in MEL is not a new concept, or even a strange concept. It's
not even what a huge chunk of the populace would call a *bad* concept.
It's ostensibly HTML. HTML is a declarative language. The way I'm
using the MEL UI code here is very much that - declarative. Perhaps
the problem here is that you're all steeped in imperative thoughts,
but honestly, I don't see much of a difference here. The examples so
far in the group are nests of functions that are honestly, woefully
less readable to me than simple indentations to 'declare' (to myself,
visually) how things line up in the hierarchy, which when it comes
down to it, is all that UIs are - they're hierarchies of containers -
but they don't ultimately change what I'm doing, or express anything
much differently. You're still creating a nesting, or a hierarchy of
controls and layouts. You just seem to want to wrap them all in
functions, which then all nest each other to create the layout. I
don't get what I win by doing that, but I do see something perhaps
minor that I clearly lose by doing that - readability (sorry, but I
do). Hierarchies are by-and-large expressed with indentations. Here's
a perfect example:

http://borumat.de/bilder/dreamweaver/html-quellcode-und-wysiwym-editor.png

Knowing only one thing about HTML itself - namely, that tags tend to
have a closing version of themselves - anyone can see immediately
what's going on. For example, I could tell in 2 seconds that the ul
element had 2 li elements, the second of which seems to have a table
element, which itself has 2 tr elements. I don't even need to know
what those are, but I can see them, and clearly, and immediately.

But why stop there? How about XML? Here's another example:

http://www.redversconsulting.co.uk/cobol/xml/cobol-xml-sample.gif

Right away, I can see that there's a TRAIN that has a LOCOMOTIVE, and
2 CARRIAGES. So can you. So can anyone, which is why they came up with
the concept of indenting blocks of siblings under their parents in
this fashion. It makes sense. It's natural.

Glade - a cross-browser UI building toolset primarily for Linux uses
XML now to store the UIs you build. Because of this, it's highly human-
readable. You can read the files it saves out just as in my examples
above, because of the indents that visually group everything. This
also means you can easily tweak things after the fact, say on apps you
download - and I have, and it was fun, and simple. Also, Glade can
load up the XML, parse it, and rebuild the UI so you can further
visually edit things, and save them back out to the XML, and the
library now works directly with the XML, instead of generating a mess
of nested code, which was the old way. The library is what you include
in your app, and you point it at the XML for your particular UI, and
it parses it when you load the program. It's elegant - the same XML is
used for 3 different purposes, and provides a helpful 4th, namely
being elegantly human-readable. Also, when you're editing in Glade,
the UI elements are presented in a tree, which shows up visually as
get this - *indented items*:

http://www.linux.ie/articles/gimp-plugin/part3/glade-tree.png

These helpful indents seem to be everywhere! :) Sorry, I don't mean to
be an ass about it.

Grant Edwards also said:
"Changing the language in order to allow authors to mislead readers is
a bad thing."

I'm not sure exactly what you mean by this, but I'm not really asking
for the language to be changed. I think mostly I'm simply pointing out
that it was very easy in MEL to express what I wanted in a simple,
straightforward, very readable way, but in Python, this seems not to
exist. I was looking for the Pythonic way to do it, but every example
so far takes this very simple concept, and makes it a rather
complicated affair, IMHO.

Jonathan Gardener said:
"cmd.build(('pane', dict(configuration='horizontal'), ('frame',
dict(l='Layouts'), (....))))"

Holy sh*t! Sorry, but that's waaay less readable. Imagine that
swelling up to hundreds of controls and layouts, all with flags, and
flag arguments. Very Lisp-like, though! I did indent that out, as you
suggested could be done, and it was passable. It still wasn't as
simple, and yes, readable as what I've been doing, which again is a
very short jump from straight XML, or HTML, but it was something I
could live with. Congrats on that.

Jason said:
"Let me add that, for lots of GUI layout, most programming languages
are the wrong tool for the job."

I can probably agree with that, but I'd like to point out that the few
that are typically used primarily for GUI layout do precisely what
I've been doing with the MEL - they indent it in a similar fashion.

He also said:
"The lack of such a layout tool is a weakness of your GUI library, not
necessarily a problem with the program language."

I don't know that the GUI library is to blame. Python came along a
decade later for Maya, where MEL had already established a simple
method for building UIs for that decade as well as it could, given its
simplicity, and limitations. Python, while not wrapping the MEL,
sought to emulate it directly, so the learning curve was minimized.
This lead to certainly non-Pythonic methods, but I don't blame the UI
for that. This was an attempt to quickly drop in another language to
give us Maya users a second option. If anything, I think it's Maya
that should provide the UI builder, because it's Maya that included
the Python, and it's for Maya that the UIs would be built,
exclusively.

However, I believe there should be a tool, and am trying to use Python
to build that tool. I've wanted it for years, and have tried a few
times in MEL, as have a few other folks, but nothing's ever come of
it, because there are no good data structures in MEL, so you first
have to do something crazy, like emulate lists, and/or dictionaries,
which I've done, but it's thousands of lines of code that took me a
year of off-and-on work to create, and it still isn't really where I
need it to be. I was eager specifically because of this to switch to
Python, but it's been a depressing, uphill battle. None of the other
languages I've used have seemed so erratic - even Perl! Don't get me
wrong, though, I do love lots of little things so far about Python,
and am still interested. I'm also interested in the possibility that
more knowledge will wipe away some of my disappointments.

gDog said:
"...I'm always intrigued by the folks who object to the indentation
rules in Python..."

But see... I don't. I LOVE that it forces proper indentation. It's
actually creates one of the warm spots in my heart in regards to
Python. I never said that Python's indentations were a bad thing. I'm
saying UI layout indentations are a GOOD thing :)

...and continues:
"...even though I've always tried to keep consistent indentation in
all the languages I've used..."

Me too. If you look through any of the quite literally tens of
thousands of lines of MEL code in my personal SVN repo, every last
line is perfectly indented. I'm manic about it. I'm the kind who will
occasionally take 15 minutes just to run through a few thousand lines
of code to double-check that it's all absolutely perfect, so I feel
better. It goes well beyond that. I even hate trailing spaces. I check
for, and trim trailing spaces all the time, and have qualms over using
anyone's code that doesn't seem to be so rigid in their clean layouts,
because it feels indicative of sloppiness in thinking to me. I have a
full style I've refined over the last decade that takes in everything
from whitespace, and capitalizations, to naming conventions, and even
spelling - all my variables are always properly spelled. My style must
absolutely be adhered to, and I fight with people to keep it all up to
spec, and don't let iditos in my code. If there's ever a problem in my
code, it will always be a logical slip-up, or as I would like to call
it - a 'true error.' It hasn't for 6 years in MEL ever been something
trivial like a typo (after the initial write/test phase).

That said, I'm almost 100% on-board with Python's style. Almost all of
it I like. I love dropping the need for all the curly braces around my
blocks, and not having to end anything beyond unindenting. It's
[usually] very freeing to code in Python, sans a few of my sticking
points.

Chris Mellon writes:
"""It's interesting that the solutions "move away from the terrible
abomination of a GUI toolkit" and "write Python wrappers that don't
cause actual physical pain" never occur to him."""

Oh, but they have, and almost immediately. You're assuming, perhaps,
however, that I have the chops for that at such an early stage in my
new Python life, or that I'm excited about the prospect of jumping
right into a new library, only to have to virtually start over,
wrapping some 15-20 layouts, and maybe 50+ controls in wrappers. In
either case, you would assume wrong.

...and continues:
"He's got a lot of years invested in this layout so I understand the
hesitance to move away from it..."

Yes! I have lots of years invested! But, no! I'm not hesitant! I'm
ready! Let's go! I'm totally prepped to be done with MEL :)

...and furthermore states:
"...but seriously - this is a really terrible way to do GUI layout."

Oh, c'mon, no it's not. It's nearly the same thing as HTML, as I said.
Are you going to seriously denounce more than a decade of that, and
tens of thousands, if not millions of people using it in every
language, in countless implementations the world over? I'm not saying
it can't be better, but *terrible?* Yes, I'm being declarative of my
layouts right inside my code, which might be weird, but that's only
because I'm adaptable, and it was the best way to do it in MEL, which
has been my only option in Maya since the mid 90s. It's been solid for
me, and honestly, once you're past a bit of the strangeness of it, is
very straightforward, and simple. It's not the best, but it's not
*terrible.*

...and keeps on rolling with:
"All those setParent calls! *shiver*."

Alright, I'll give you those :) I hated them for the first year.
Still, they're basically just HTML close tags, with the added power
that you can replace '..' with a specific layout to jump into that.
You can also think of them as close braces in your choice of C-like
languages. Don't be such a scaredy-cat.

...will he ever stop? I don't know:
"I notice he retreats to the "well, *I* can read it, so it's not
unreadable" defense..."

I can read it, because it's a natural style, as seen all over the
place in HTML, XML, many UI layout tools, folder trees, complicated
task lists, book outlines, and the list goes on. Seriously, what is
with you people?

...and is almost done with:
"I know people who can read x86 assembly directly from hex dumps"

I rather enjoyed coding in x86, and once created a SWF file (compiled
Flash binary), by hand, entirely at the *bit* (not byte) level. It
took hours to get only several hundred bytes, but it worked! This, I
realize, is not a good argument in my favor.

...and FINALLY finishes:
"without really addressing the merits of a particular case."

But I have, over and over. It's very readable. It's a hierarchy of
layouts and controls, expressed in a hierarchy of indented blocks that
match up 1:1 with each other.

What I've noticed is that no one in here as yet has backed themselves
up. Let me pick one, without creating an exhaustive list:

Jonathan Gardener promised this:
"...let me try to explain why you'd never want to indent code that
way, let alone write code that way."

But then never actually explained it.

He states:
"...it's best to create functions and then nest the functions."

But never says why it's best - just that it is. None of you so far
have said why your thoughts have any merit. So far, it's just all been
declarative statements that your ways are better, that my ways are
"terrible," and all with not one substantiation of either sentiment.
Weren't any of you folks in debate club? I wasn't, but I think I'm
winning :)

Please don't regard any of the above as the embers of an impending
flame war. I'm not interested in fighting, really. I'm here
specifically because I'm interested in Python now, and it sounds like
you guys might know something important that I don't, and I'd like to
know what that might be. I'm always interested in learning, so teach
me already! Thanks for reading all of this, if you did indeed do so.