up with PyGUI!
OKB (not okblacke)
brenNOSPAMbarn at NObrenSPAMbarn.net
Sun Sep 26 04:31:33 CEST 2004
Ed Leafe wrote:
> I am interested in any alternatives that would benefit our users;
> my curiosity is about the payoff for adopting an alternative
> approach such as yours. If such a payoff isn't there, I can't spend
> a lot of time pursuing it. That's why I'm constantly asking you to
> explain the benefit, not just the theory, behind this idea.
Well, admittedly I've only begun doing this, but my idea is that
the benefit is in readability. Suppose your code is structured like
def __init__(self, parent):
button1 = wxButton(parent=self, ...)
button2 = wxButton(parent=self...)
panel = wxPanel(parent=self...)
listBox1 = wxComboBox(parent=panel...)
listBox2 = wxComboBox(parent=panel...)
button3 = wxButton(parent=panel...)
text = wxTextCtrl(parent=panel...)
sizer1 = wxBoxSizer(...)
sizer2 = wxBoxSizer(...)
How am I supposed to know, just by looking at that, which
controls are in which sizers and what the relationship is between the
two sizers? I have to visually parse every single line -- not just the
creation of each widget, but also the line that adds it to a sizer. And
there could easily be an inconsistency -- you might accidentally give a
widget a parent that's inconsistent with the sizer you add it to. With
a nested structure it becomes clear:
# name, size, etc.
class listBox1(wxComboBox): # etc.
class listBox2(wxComboBox): # etc.
class button3(wxButton): # etc.
class text(wxTextCtrl): # etc.
Now, I can see your point: this does amount to essentially an abuse
of the "class" keyword. But to me this is a small price to pay for the
increase in readability and the reduction in redundancy. Why should I
have to separately specify that: a) a certain widget is being created;
b) it has a certain parent; c) it goes in a certain sizer; c) that sizer
goes in the parent widget? I regard these all as essentially
restatements of a single overall fact about the widget's position in the
So, yes, this is a very unusual use for the word "class". But the
point here is not the keywords being used. The idea is to have the
structure of the GUI reflected clearly in the layout of the code. If
Python's syntax were more flexible, this could perhaps be done in other
ways -- I'm not saying I want that -- but as it is the only real way to
construct nested structures in Python is with class definitions.
--OKB (not okblacke)
"Do not follow where the path may lead. Go, instead, where there is
no path, and leave a trail."
More information about the Python-list