Allowing Arbitrary Indentation in Python

Gary gfixler at gmail.com
Wed Dec 19 22:46:50 EST 2007


On Dec 19, 3:50 pm, "Chris Mellon" <arka... at gmail.com> wrote:

> You have been done a disservice
> by whoever wrote the Maya python bindings, as far as using this tool
> to improve your knowledge and understanding of Python goes.

No worries there. I'm definitely not using Maya as the way to learn
Python. I'm using it as the reason to learn it, with additional
supporting reasons being that it aids me in the shell, opens up
libraries (and thus abilities) like PyGTK, and can help me create the
kinds of tools I create for myself on Linux, but with a lot more
power, and expressed more intelligently.

> Yes, HTML is a very bad way of doing GUI layout. It's a textual markup
> language, not a layout format. HTML per se has almost no layout
> capabilities at all, and CSS while much better is still quite limited.

Fair enough. I would say in this sense, it feels similar to the
concept of duck typing to me. The UI sections of my MEL code looked
(to me) like HTML, and were formed in the same way, and the output was
essentially a 1:1 mapping of what similar, declarative, HTML-style
markup might produce. That it was clearly *not* what it seemed to be
was beside the point. It quacked like a duck for me, and always got
the job done. But I'm ready for a real duck now.

> This is the internet, we don't shy away from scoffing at millions of
> misguided souls here ;)

I wrote that bit, admittedly, with a dark grin on my face. I often
find I disagree with the majority. I suppose I was being a *bit*
defensive, though. After all, I was - ostensibly - doing the same
thing in my code that one would do in HTML. That I was violating laws
of code (codes of law?) was very much an extension of the fact that I
really didn't have a choice. After all, I did try unsuccessfully
several times (as have others) to create a system whereby I'd design
the layouts in an editor, and save them out to some declarative
format. However, in that I needed to create a rather intricate UI in
MEL that could create UIs in MEL, with the terrible UI abilities in
MEL, and using MEL itself, which is vastly underpowered, it was
something more fit for an entire ship of fools to create, rather than
one lone code warrior. It was just too much work. I think it will be
not only possible, but end up rather powerful to create it in Python.

> > ...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.
>
> They aren't a close tag, they're state management, and the fact that
> you have to litter your code with them is a real flaw in the GUI
> toolkit.

I agree. I've known that I'm simply manipulating states, but the
overarching points here are that it was my only real option, and I
managed to dress it up prettily enough that I could fool myself, and
not be bothered by it. It helps that I own all my code, and that it's
only been used by 2-4 people these past 6 years. Now that the company
is growing, and I'm wanting more to share code, and build more
powerful things, I'm eager to shed some of my youthful, carefree ways,
and code properly, and powerfully.

> > 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 :)
>
> I'm not him, but I'll say why *I* might have said this. What you're
> doing with your nesting is creating and managing a stack of states. It
> just so happens that you have a very powerful programming language all
> ready to do this for you, because that's exactly what it does when you
> make nested function calls. So rather than writing imperative code
> that tries to look declarative, you can just write imperative code (or
> you could use/invent a real declarative language for declaring these
> GUIs, and load the UI from that. This is what GUI builders like Glade
> do). Remember that you are *not* writing markup. You are writing code
> in a real programming language and you have all the power of that
> language at your disposal for breaking code down into small, easily
> handled pieces. I too have written UIs that scale to hundreds of
> individual GUI elements (although not neccesarily controls, because a
> UI screen that cluttered is hard ot use) and the way to manage the
> complexity is the same way you manage any other programming complexity
> - by breaking it into pieces which you gradually compose together.

That's where I'm leaning. As I mentioned to Grant earlier, it looks
like I'm going to want to write wrappers that a parser can call out to
build UIs based on UI data stored in XML. I still can't get away from
the fact that somewhere, I need to setParent, but it can be tied up,
and hidden in the basement, at least. So that's the next two
questions:

1) Is it best/more standard to read in, and parse the XML into some
kind of Python hierarchy first, and then build the UI out of the data
in that structure, or call out UI commands as say, callbacks from the
parser live - as it wades through the data? I lean toward the former,
as it means having one standard set of functions to read in, and parse
the XML data, which can then be used for anything, like displaying the
UI to the client, or creating an editable version of the UI in the UI
build tool. The modified version can then be saved back out as well.

2) Is XML fairly standard for this in Python? I recently learned about/
was frightened by pickling. Is that worth learning? Does anyone bother
with it?

Thanks, Chris.
-g



More information about the Python-list mailing list