Allowing Arbitrary Indentation in Python

Jason tenax.raccoon at gmail.com
Tue Dec 18 20:13:36 EST 2007


On Dec 18, 5:18 pm, Sam <L33tmin... at gmail.com> wrote:
> On Dec 18, 7:09 pm, Jonathan Gardner
>
>
>
> <jgardner.jonathangardner.... at gmail.com> wrote:
> > On Dec 18, 2:16 pm, Sam <L33tmin... at gmail.com> wrote:
>
> > > 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



More information about the Python-list mailing list