Allowing Arbitrary Indentation in Python

[Sam]

A friend of mine is picking up some Python and is frustrated by
Python's indentation rules (http://greatbiggary.livejournal.com/
260460.html?thread=1835884#t1835884). Personally, I've never had any
issues with Python's ways of indentation, but that conversation got me
thinking about the issue.

Consider the following indentation rules:
1. Blocks begin with a line ending in ":"
2. A line on the same indentation level or lower ends a block.

Under those rules, this would work:
layouts = ['column', 'form', 'frame']
cmds.window(t='gwfUI Builder')
cmds.paneLayout(configuration='vertical3', ps=((1, 25, 100), (3, 20,
100)))
cmds.paneLayout(configuration='horizontal2')
cmds.frameLayout(l='Layouts')
cmds.scrollLayout(cr=True)
cmds.columnLayout(adj=True, cat=('both', 2))
for i in layouts:
cmds.button(l=i)
cmds.setParent('..')
cmds.setParent('..')
cmds.setParent('..')
cmds.setParent('..')
cmds.setParent('..')
cmds.showWindow()

Do such rules make sense? Is there any way to make code work that way
in Python? Should there be? Does that make this sort of code more or
less readable?

P.S. I'm definitely not looking for a tabs vs. spaces flamewar here.
That's a different issue.

[Jonathan Gardner]

On Dec 18, 2:16 pm, Sam <[e-mail]:

layouts = ['column', 'form', 'frame']
cmds.window(t='gwfUI Builder')
cmds.paneLayout(configuration='vertical3', ps=((1, 25, 100), (3, 20,
100)))
cmds.paneLayout(configuration='horizontal2')
cmds.frameLayout(l='Layouts')
cmds.scrollLayout(cr=True)
cmds.columnLayout(adj=True, cat=('both', 2))
for i in layouts:
cmds.button(l=i)
cmds.setParent('..')
cmds.setParent('..')
cmds.setParent('..')
cmds.setParent('..')
cmds.setParent('..')
cmds.showWindow()

While Grant is pulling his hair out and yelling obscenities at the
moon, let me try to explain why you'd never want to indent code that
way, let alone write code that way.

In cases where you have to run a sequence of code in a nested way,
like this, it's best to create functions and then nest the functions.
Of course, I'm thinking more of a lisp solution and less of a C one.

In this case, you're going to have to have objects (or data
structures) that know what to do to execute the commands necessary.
When you get them all assembled, you simply run them in a recursive
way.

For instance:

cmd.build(('pane', dict(configuration='horizontal'), ('frame',
dict(l='Layouts'), (....))))

You can indent these arbitrarily. Plus, you don't have to worry too
much about matching setParent and the other commands.

[Sam]

On Dec 18, 7:09 pm, Jonathan Gardner
<[e-mail]:

On Dec 18, 2:16 pm, Sam <[e-mail]:

layouts = ['column', 'form', 'frame']
cmds.window(t='gwfUI Builder')
cmds.paneLayout(configuration='vertical3', ps=((1, 25, 100), (3, 20,
100)))
cmds.paneLayout(configuration='horizontal2')
cmds.frameLayout(l='Layouts')
cmds.scrollLayout(cr=True)
cmds.columnLayout(adj=True, cat=('both', 2))
for i in layouts:
cmds.button(l=i)
cmds.setParent('..')
cmds.setParent('..')
cmds.setParent('..')
cmds.setParent('..')
cmds.setParent('..')
cmds.showWindow()

While Grant is pulling his hair out and yelling obscenities at the
moon, let me try to explain why you'd never want to indent code that
way, let alone write code that way.

In cases where you have to run a sequence of code in a nested way,
like this, it's best to create functions and then nest the functions.
Of course, I'm thinking more of a lisp solution and less of a C one.

In this case, you're going to have to have objects (or data
structures) that know what to do to execute the commands necessary.
When you get them all assembled, you simply run them in a recursive
way.

For instance:

cmd.build(('pane', dict(configuration='horizontal'), ('frame',
dict(l='Layouts'), (....))))

You can indent these arbitrarily. Plus, you don't have to worry too
much about matching setParent and the other commands.

That makes sense to me. The library that was being used in that
example didn't strike me as very Pythonic (what with the using one
command object for everything and calling setParent('..') to point to
the next object up in the hierarchy). But there's no reason (as far
as I know) that he couldn't create helper functions to wrap that with
something more sane.

[Jason]

On Dec 18, 5:18 pm, Sam <[e-mail]:

On Dec 18, 7:09 pm, Jonathan Gardner

<[e-mail]:

On Dec 18, 2:16 pm, Sam <[e-mail]:

layouts = ['column', 'form', 'frame']
cmds.window(t='gwfUI Builder')
cmds.paneLayout(configuration='vertical3', ps=((1, 25, 100), (3, 20,
100)))
cmds.paneLayout(configuration='horizontal2')
cmds.frameLayout(l='Layouts')
cmds.scrollLayout(cr=True)
cmds.columnLayout(adj=True, cat=('both', 2))
for i in layouts:
cmds.button(l=i)
cmds.setParent('..')
cmds.setParent('..')
cmds.setParent('..')
cmds.setParent('..')
cmds.setParent('..')
cmds.showWindow()

While Grant is pulling his hair out and yelling obscenities at the
moon, let me try to explain why you'd never want to indent code that
way, let alone write code that way.

In cases where you have to run a sequence of code in a nested way,
like this, it's best to create functions and then nest the functions.
Of course, I'm thinking more of a lisp solution and less of a C one.

In this case, you're going to have to have objects (or data
structures) that know what to do to execute the commands necessary.
When you get them all assembled, you simply run them in a recursive
way.

For instance:

cmd.build(('pane', dict(configuration='horizontal'), ('frame',
dict(l='Layouts'), (....))))

You can indent these arbitrarily. Plus, you don't have to worry too
much about matching setParent and the other commands.

That makes sense to me. The library that was being used in that
example didn't strike me as very Pythonic (what with the using one
command object for everything and calling setParent('..') to point to
the next object up in the hierarchy). But there's no reason (as far
as I know) that he couldn't create helper functions to wrap that with
something more sane.

Let me add that, for lots of GUI layout, most programming languages
are the wrong tool for the job. GUI layout involves tons of nested,
almost boiler-plate type data. Use a tool to generate the layout that
the code can load, and perform the few tweaks that you might need.
This makes things far more sane, especially for anyone who has to
maintain the layout later.

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

--Jason

[Grant Edwards]

On 2007-12-19, Jonathan Gardner <jg**************************@gmail.comwrote:

On Dec 18, 2:16 pm, Sam <[e-mail]:

>layouts = ['column', 'form', 'frame']
cmds.window(t='gwfUI Builder')
cmds.paneLayout(configuration='vertical3', ps=((1, 25, 100), (3, 20,
100)))
cmds.paneLayout(configuration='horizontal2')
cmds.frameLayout(l='Layouts')
cmds.scrollLayout(cr=True)
cmds.columnLayout(adj=True, cat=('both', 2))
for i in layouts:
cmds.button(l=i)
cmds.setParent('..')
cmds.setParent('..')
cmds.setParent('..')
cmds.setParent('..')
cmds.setParent('..')
cmds.showWindow()

While Grant is pulling his hair out and yelling obscenities at the
moon,

Damn. I thought that webcam was shut off...

--
Grant

[gDog]

Hi, Sam-

I'm not wanting to start a flame war, either, but may I ask why does
your friend want to do that? I'm always intrigued by the folks who
object to the indentation rules in Python, even though I've always
tried to keep consistent indentation in all the languages I've used
(and I've been at this since the 1980's). Even my Perl coding friends
tend to insist on indents being aligned. I'm just curious, that's
all.

Thanks,
--greg

[Sam]

On Dec 19, 11:09 am, gDog <[e-mail]:

Hi, Sam-

I'm not wanting to start a flame war, either, but may I ask why does
your friend want to do that? I'm always intrigued by the folks who
object to the indentation rules in Python, even though I've always
tried to keep consistent indentation in all the languages I've used
(and I've been at this since the 1980's). Even my Perl coding friends
tend to insist on indents being aligned. I'm just curious, that's
all.

Thanks,
--greg

His comments on the subject are in the LiveJournal comment I linked to
in my original post. I think it's mostly an idiosyncratic thing; he's
used to laying out GUI elements in a hierarchy using tabs (in some
language that allows arbitrary tabs) and now that he's experimenting
with the (new?) Python API for the same toolkit, he wishes he could
use the same coding style.

[Chris Mellon]

On Dec 19, 2007 10:46 AM, Sam <L3********@gmail.comwrote:

On Dec 19, 11:09 am, gDog <[e-mail]:

Hi, Sam-

I'm not wanting to start a flame war, either, but may I ask why does
your friend want to do that? I'm always intrigued by the folks who
object to the indentation rules in Python, even though I've always
tried to keep consistent indentation in all the languages I've used
(and I've been at this since the 1980's). Even my Perl coding friends
tend to insist on indents being aligned. I'm just curious, that's
all.

Thanks,
--greg

His comments on the subject are in the LiveJournal comment I linked to
in my original post. I think it's mostly an idiosyncratic thing; he's
used to laying out GUI elements in a hierarchy using tabs (in some
language that allows arbitrary tabs) and now that he's experimenting
with the (new?) Python API for the same toolkit, he wishes he could
use the same coding style.

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. He's got a lot of
years invested in this layout so I understand the hesitance to move
away from it, but seriously - this is a really terrible way to do GUI
layout. The context manager solution is probably the best way to
maintain something close to the style he's used to.

All those setParent calls! *shiver*. I notice he retreats to the
"well, *I* can read it, so it's not unreadable" defense, which of
course applies to anything (I know people who can read x86 assembly
directly from hex dumps) without really addressing the merits of a
particular case.

[Grant Edwards]

On 2007-12-19, Gary <gf*****@gmail.comwrote:

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):

The problem is that to everybody else in the world, indentation
in Python represents control flow nesting, not GUI widget
nesting.

Even assuming people can learn new things (in my experience an
assumption to be somewhat avoided if possible), under your
proposal indentation _sometimes_ represents control flow
nesting, and sometimes doesn't. That imposes a much greater
burden on the reader: they've got to spend a lot more mental
energy to figure out whether the indentation of each line
represents control flow or something else. That's a bad thing(TM)

--
Grant Edwards grante Yow! MERYL STREEP is my
at obstetrician!
visi.com

[Gary]

On Dec 19, 3:19 pm, Grant Edwards <[e-mail]:

The problem is that to everybody else in the world, indentation
in Python represents control flow nesting, not GUI widget
nesting.

Thanks, Grant. That's the first solid reasoning I've seen, and it's a
very solid argument, as well. To that end, I'm thinking a few things.
For one, your argument correctly puts forth that using the code in 2
separate ways is not good. Despite doing just that for 6 years with no
problems, I can agree with you on that point. For another, I don't
really think the proposals, or hints at how to do it in Python are all
that great, either, because they create what I believe to be a bigger
mess.

I'm kind of leaning toward a Glade approach, wherein I wrap the UI
elements up with an XML parser (I'm sure those exist for me already),
and have some set of UI building functions build the UI for me with
the crappy Maya calls underneath, based on data extracted from the
XML. Then the UIs would be built as part of the parsing effort. This
sort of hides the ugly stepchild of the Maya method of creating UIs
under calls that each only do one thing, which rids the need to nest
anything directly in Python, and separates out the UI data into XML -
a language specifically made to be indented in a readable fashion,
perfect for UI information. The extra benefit is that UI snippets can
then be reused in the manner of templates, and even 'widgets,' from
which all of my UIs can potentially benefit. I'm sure there's more to
think about in regards to all of this, but it's not only the basis for
a game plan, but it has precedent in places like Glade, to suggest
that it's a viable, and decent option.

Again, thanks.
-g

[Chris Mellon]

On Dec 19, 2007 4:05 PM, Gary <gf*****@gmail.comwrote:

<snipped a lot of stuff I'm not replying to>>

>
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.

I overestimated your Python experience when I read the first (last?
most recent) post. After I sent the email I went back through your LJ
post where your level of experience with Python is made much more
plain. I don't mean this in a bad way - you're a beginner and that's
fine - but you don't have a grasp on Pythons fundamentals and thats
why so many things about it seem strange to you. All of the things in
your first post have reasons why they are that way, and there is
internal consistency in all of them. 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.

...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?

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.
This is the internet, we don't shy away from scoffing at millions of
misguided souls here ;)

>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.*

It's very much like writing HTML using only the DOM apis, and not
HTMLs syntatic markup, which *is* terrible.
The structures you're defining are quite reasonable, it's the API
that's bad. I tend to group stuff into categories of "good",
"adequate", and "terrible". This, from the API alone, falls squarely
into "terrible" for me.

...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. You'll note that my language of choice is Python, a language
which explicitly *excluded* the need for an "end block" marker. I'm
pretty sure that there's a way to write Python that looks like the UI,
but it's not using the API you have.

...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?

I'm not so much claiming it's unreasonable as dismissing your argument
why it is. I have to re-iterate: It's *not* markup. It's imperative
code full of explicit state management that you write in a way that
*llooks* like markup, which is a good call on your part because theres
a reason almost everyone uses declarative languages for UI layout
these days.

...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.

This is where the Ruby and Lisp people will come in and gloat about
DSLs, because that's what you've been doing - you've invented a very
simple sort of DSL and embedded in your host language, which happens
to syntatically support the DSL you've chosen. You can do the same
thing in Python, but you have different syntax constraints to conform
to.

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 :)

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.

[Ross Ridge]

Sam <L3********@gmail.comwrote:

>cmds.window(t='gwfUI Builder')
cmds.paneLayout(configuration='vertical3', ps=((1, 25, 100), (3, 20,
100)))
cmds.paneLayout(configuration='horizontal2')
cmds.frameLayout(l='Layouts')
cmds.scrollLayout(cr=True)
cmds.columnLayout(adj=True, cat=('both', 2))
for i in layouts:
cmds.button(l=i)
cmds.setParent('..')
cmds.setParent('..')
cmds.setParent('..')
cmds.setParent('..')
cmds.setParent('..')
cmds.showWindow()

An alternative would be to do something like the following:

cmds.window(t='gwfUI Builder')
cmds.paneLayout(configuration='vertical3', ps=((1, 25, 100),
(3, 20, 100)))
cmds. paneLayout(configuration='horizontal2')
cmds. frameLayout(l='Layouts')
cmds. scrollLayout(cr=True)
cmds. columnLayout(adj=True, cat=('both', 2))
for i in layouts:
cmds. button(l=i)
cmds. setParent('..')
cmds. setParent('..')
cmds. setParent('..')
cmds. setParent('..')
cmds.setParent('..')
cmds.showWindow()

Stylistically it's not much better, but you don't need to change Python
interpreter for it work.

Ross Ridge

--
l/ // Ross Ridge -- The Great HTMU
[oo][oo] rr****@csclub.uwaterloo.ca
-()-/()/ http://www.csclub.uwaterloo.ca/~rridge/
db //

[Gary]

On Dec 19, 3:50 pm, "Chris Mellon" <[e-mail]:

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

[Gary]

On Dec 19, 6:44 pm, Ross Ridge <[e-mail]>
wrote:

Sam <[e-mail]:

cmds.window(t='gwfUI Builder')
cmds.paneLayout(configuration='vertical3', ps=((1, 25, 100), (3, 20,
100)))
cmds.paneLayout(configuration='horizontal2')
cmds.frameLayout(l='Layouts')
cmds.scrollLayout(cr=True)
cmds.columnLayout(adj=True, cat=('both', 2))
for i in layouts:
cmds.button(l=i)
cmds.setParent('..')
cmds.setParent('..')
cmds.setParent('..')
cmds.setParent('..')
cmds.setParent('..')
cmds.showWindow()

An alternative would be to do something like the following:

cmds.window(t='gwfUI Builder')
cmds.paneLayout(configuration='vertical3', ps=((1, 25, 100),
(3, 20, 100)))
cmds. paneLayout(configuration='horizontal2')
cmds. frameLayout(l='Layouts')
cmds. scrollLayout(cr=True)
cmds. columnLayout(adj=True, cat=('both', 2))
for i in layouts:
cmds. button(l=i)
cmds. setParent('..')
cmds. setParent('..')
cmds. setParent('..')
cmds. setParent('..')
cmds.setParent('..')
cmds.showWindow()

Stylistically it's not much better, but you don't need to change Python
interpreter for it work.

I'm adding this to my list of crazy things not to do :) I'm also
adding it to my list of code snippets I can use to injure Python
programmers, if the need arises. Thanks!

-g

[Gary]

On Dec 19, 6:44 pm, Ross Ridge <[e-mail]>
wrote:

Sam <[e-mail]:

cmds.window(t='gwfUI Builder')
cmds.paneLayout(configuration='vertical3', ps=((1, 25, 100), (3, 20,
100)))
cmds.paneLayout(configuration='horizontal2')
cmds.frameLayout(l='Layouts')
cmds.scrollLayout(cr=True)
cmds.columnLayout(adj=True, cat=('both', 2))
for i in layouts:
cmds.button(l=i)
cmds.setParent('..')
cmds.setParent('..')
cmds.setParent('..')
cmds.setParent('..')
cmds.setParent('..')
cmds.showWindow()

An alternative would be to do something like the following:

cmds.window(t='gwfUI Builder')
cmds.paneLayout(configuration='vertical3', ps=((1, 25, 100),
(3, 20, 100)))
cmds. paneLayout(configuration='horizontal2')
cmds. frameLayout(l='Layouts')
cmds. scrollLayout(cr=True)
cmds. columnLayout(adj=True, cat=('both', 2))
for i in layouts:
cmds. button(l=i)
cmds. setParent('..')
cmds. setParent('..')
cmds. setParent('..')
cmds. setParent('..')
cmds.setParent('..')
cmds.showWindow()

Stylistically it's not much better, but you don't need to change Python
interpreter for it work.

I'm adding this to my list of crazy things not to do :) I'm also
adding it to my list of code snippets I can use to injure Python
programmers, if the need arises. Thanks!

-g

[Gary]

On Dec 19, 7:01 pm, "Terry Reedy" <[e-mail]:

Hi, Gary. Welcome to Python. I hope you will take some of the reaction
you got as initiatory ribbing.

Thanks, Terry, and absolutely! You guys are quite tame compared to
some of the lions whose dens I've stumbled into on usenet. You're also
all well-spoken, passionate, and informative. I'm thinking of sticking
around in here while the learning's good.

Anyone who loves Python obvious likes the idea of meaningful indentation.
The problem with your suggestion and example is with mixing two meanings in
the same hierarchy. Hence the suggestion that you separate program text
and declarative text.

It would seem that's been the biggest stumbling block - my wanton
mixing of imperative and declarative styles. I did do my best to
separate them geographically in my scripts - with the UI bits always
coming at the end :) I've made my justifications above - namely that
"Hey, it always worked fine!" and "Sorry, but there wasn't much in the
way of options," - but I'm quite ready to do things cleanly, properly,
extensibly, and Pythonically.

| I'm not sure exactly what you mean by this, but I'm not really asking
| for the language to be changed.

You fooled me as well as others.

Sorry about that. I most definitely didn't want to have Python fork,
or change into some version compatible with my mind. I was mostly
stamping my feet, and whining about how all the options for doing what
I must do all the time seemed so overly complicated in comparison to
what I've already been doing. The full separation of the declarative
portion is the right answer to my problem, though, and requires no
changes, except to my methodology, and in that, only for the better.

A reasonable question would be something like this. "I currently do gui
layout with MEL [what is that?] and like this but not that. I am looking
at Python because of X. How do people express gui layout within or in
conjuction with Python code?"

Fair enough. Of course, if I'd actually posted to this newsgroup in
the first place, I probably would have stated it in a very similar
way. I'm quite polite, and descriptive in newsgroups, usually. This
was cross-posted to here from my LJ by my online friend, Sam, as an
unintended surprise gift to me :) Really, he was just curious about
what this group would have to say about my problems, and when he told
me of his crosspost, I was immediately quite interested as well. It
worked out for me, too, because now I have a better sense of the right
ways to go about a task I must do too often not to do intelligently.

Thanks for your help, Terry.
-g

[Gary]

On Dec 19, 7:01 pm, "Terry Reedy" <[e-mail]:

Hi, Gary. Welcome to Python. I hope you will take some of the reaction
you got as initiatory ribbing.

Thanks, Terry, and absolutely! You guys are quite tame compared to
some of the lions whose dens I've stumbled into on usenet. You're also
all well-spoken, passionate, and informative. I'm thinking of sticking
around in here while the learning's good.

Anyone who loves Python obvious likes the idea of meaningful indentation.
The problem with your suggestion and example is with mixing two meanings in
the same hierarchy. Hence the suggestion that you separate program text
and declarative text.

It would seem that's been the biggest stumbling block - my wanton
mixing of imperative and declarative styles. I did do my best to
separate them geographically in my scripts - with the UI bits always
coming at the end :) I've made my justifications above - namely that
"Hey, it always worked fine!" and "Sorry, but there wasn't much in the
way of options," - but I'm quite ready to do things cleanly, properly,
extensibly, and Pythonically.

| I'm not sure exactly what you mean by this, but I'm not really asking
| for the language to be changed.

You fooled me as well as others.

Sorry about that. I most definitely didn't want to have Python fork,
or change into some version compatible with my mind. I was mostly
stamping my feet, and whining about how all the options for doing what
I must do all the time seemed so overly complicated in comparison to
what I've already been doing. The full separation of the declarative
portion is the right answer to my problem, though, and requires no
changes, except to my methodology, and in that, only for the better.

A reasonable question would be something like this. "I currently do gui
layout with MEL [what is that?] and like this but not that. I am looking
at Python because of X. How do people express gui layout within or in
conjuction with Python code?"

Fair enough. Of course, if I'd actually posted to this newsgroup in
the first place, I probably would have stated it in a very similar
way. I'm quite polite, and descriptive in newsgroups, usually. This
was cross-posted to here from my LJ by my online friend, Sam, as an
unintended surprise gift to me :) Really, he was just curious about
what this group would have to say about my problems, and when he told
me of his crosspost, I was immediately quite interested as well. It
worked out for me, too, because now I have a better sense of the right
ways to go about a task I must do too often not to do intelligently.

Thanks for your help, Terry.
-g

[Gabriel Genellina]

En Thu, 20 Dec 2007 00:46:50 -0300, Gary <gf*****@gmail.comescribió:

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.

ElementTree is a good candidate for processing xml:
http://effbot.org/zone/element.htm
It provides a "natural" way to access elements and attributes, instead of
writing the same handler again and again or using slow DOM functions of
gigantic names.

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?

Pickle is good for storing data that will be loaded again by (the same, or
another) Python program. The format isn't portable to other languages, it
isn't readable, may have security issues. But it's extensible and much
more flexible than the other builtin alternative, marshal. You can use
pickle as a serializer if you're aware of its limitations.

--
Gabriel Genellina

[Gary]

On Dec 19, 10:10 pm, "Gabriel Genellina" <[e-mail]>
wrote:

ElementTree is a good candidate for processing xml: http://effbot.org/zone/element.htm
It provides a "natural" way to access elements and attributes, instead of
writing the same handler again and again or using slow DOM functions of
gigantic names.

That does look pretty easy. I'll look into it after I get back from
the holidays.

Thanks, Gabriel.
-g

[Gary]

On Dec 19, 10:10 pm, "Gabriel Genellina" <[e-mail]>
wrote:

ElementTree is a good candidate for processing xml: http://effbot.org/zone/element.htm
It provides a "natural" way to access elements and attributes, instead of
writing the same handler again and again or using slow DOM functions of
gigantic names.

That does look pretty easy. I'll look into it after I get back from
the holidays.

Thanks, Gabriel.
-g