Fixed this (see below) but have another syntax error I haven't fixed.
self.SetSizer(self.outerBox)
self.SetSizer(outerBox) # fixes original problem
The following is throwing the error, but it is the same as on the tutorial
page:
self.sizer.Fit(self)
Traceback (most recent call last):
File "./pw.py", line 92, in <module>
frame = MainFrame(None, "PermitWatch")
File "./pw.py", line 65, in __init__
self.sizer.Fit(self)
AttributeError: 'MainFrame' object has no attribute 'sizer'
sizers don’t have a Fit method… a panel or frame does though (because they inherit from wx.Window)… just remove the sizer from your call so it’s like:
self.Fit(self)
P.S. I think it’s better netiquette to update the original post, rather than creating a new thread with UPDATE in the name. It destroys the linked-list/parent-child history of messages that are connected to each other.
···
On Monday, July 7, 2014 2:44:02 PM UTC-7, fuzzydoc wrote:
On Mon, 7 Jul 2014, Rich Shepard wrote:
Fixed this (see below) but have another syntax error I haven’t fixed.
self.SetSizer(self.outerBox)
self.SetSizer(outerBox) # fixes original problem
The following is throwing the error, but it is the same as on the tutorial
page:
self.sizer.Fit(self)
Traceback (most recent call last):
File “./pw.py”, line 92, in
frame = MainFrame(None, "PermitWatch")
File “./pw.py”, line 65, in init
self.sizer.Fit(self)
AttributeError: ‘MainFrame’ object has no attribute ‘sizer’
sizers don't have a Fit method... a panel or frame does though (because
they inherit from wx.Window)... just remove the sizer from your call so
it's like:
self.Fit(self)
P.S. I think it's better netiquette to update the original post, rather
than creating a new thread with UPDATE in the name. It destroys the
linked-list/parent-child history of messages that are connected to each
other.
I was updating the original post. Does adding [UPDATE] to the subject
create a new thread? Haven't seen that on mailman-managed lists. Will leave
out subject line suffix from now on.
Fixed this (see below) but have another syntax error I haven't fixed.
self.SetSizer(self.outerBox)
self.SetSizer(outerBox) # fixes original problem
The following is throwing the error, but it is the same as on the
tutorial
page:
self.sizer.Fit(self)
Traceback (most recent call last):
File "./pw.py", line 92, in <module>
frame = MainFrame(None, "PermitWatch")
File "./pw.py", line 65, in __init__
self.sizer.Fit(self)
AttributeError: 'MainFrame' object has no attribute 'sizer'
Since you had this sort of error twice now, may I chip in a
quasi-philosophical and Python-relevant point, Rich? The good news is
that, at least to me, the AttributeError is often the easiest one to hunt
down the problem, but it requires that you "really believe" the error
message. That is, if it says that MainFrame does not have some object
named "sizer", then that means that you somewhere have "self.sizer" being
used (since "self" refers to the instance of, in your case, the "MainFrame"
class) but you never defined what "self.sizer" is anywhere, so the
interpreter is thinking, "What does he mean, self.sizer? Where did he say
self has this thing called sizer?"
I know when I was earlier in programming in Python/wxPython these sorts of
errors confused me, but now I am sort of relieved, because I know I merely
forgot to put a self.sizer = ..... somewhere and it's an easy bug to fix.
···
On Mon, Jul 7, 2014 at 5:43 PM, Rich Shepard <rshepard@appl-ecosys.com> wrote:
On Mon, 7 Jul 2014, Rich Shepard wrote:
Please correct my syntax error.
Rich
--
You received this message because you are subscribed to the Google Groups
"wxPython-users" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to wxpython-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
If I may chip in - I also was confused by AttributeErrors early on (mostly
because Python was the first language where I actually "got" what object
orientation is all about!), but now I almost welcome them because... well,
if I'm going to make a mistake, at least it's an easy one to catch, right?
More to the point, though, this question seems to me like an excellent
demonstration of why generic-sounding variable names are a terrible idea.
I realize that you're working from someone else's code, but if he could
hear I would tell him too: DON'T name your sizers "sizer". Call them
MySizer, or Edger, or OuterBound, or... well, just about _anything_ that
doesn't make them sound like a built-in, generic property. This sort of
confusion - where a user-created attribute gets confused with a generic
property - happens all too often. The interpreter doesn't care at all what
you name your variables - so make them easy to identify, understand, and
remember.
(One option I've occasionally used - I'm not recommending it as standard
practice, but it has worked for me - is to use a foreign language for my
variable names. If a variable has a clear meaning, by all means name it
appropriately - GrandTotal, for example - but I might call a generic sizer
"self.calibreur", just to make sure I won't
···
On Mon, Jul 7, 2014 at 4:32 PM, C M <cmpython@gmail.com> wrote:
The good news is that, at least to me, the AttributeError is often the
easiest one to hunt down the problem, but it requires that you "really
believe" the error message. That is, if it says that MainFrame does not
have some object named "sizer", then that means that you somewhere have
"self.sizer" being used (since "self" refers to the instance of, in your
case, the "MainFrame" class) but you never defined what "self.sizer" is
anywhere, so the interpreter is thinking, "What does he mean, self.sizer?
Where did he say self has this thing called sizer?"
That's an excellent point, Marc! Naming a sizer "sizer" is just asking for
trouble, particularly as a beginner, for exactly the reasons you give.
I am unashamedly a user of long inelegant object names, even to the point
of backgroundSizerForMainFrame or textCtrlForTheUsersCookieRecipe. You are
just not going to have an instant's confusion when debugging as to what
those objects are. (The less confused instants I have, the better. There
are still many, though :\ ).
···
On Mon, Jul 7, 2014 at 7:53 PM, Marc Tompkins <marc.tompkins@gmail.com> wrote:
On Mon, Jul 7, 2014 at 4:32 PM, C M <cmpython@gmail.com> wrote:
The good news is that, at least to me, the AttributeError is often the
easiest one to hunt down the problem, but it requires that you "really
believe" the error message. That is, if it says that MainFrame does not
have some object named "sizer", then that means that you somewhere have
"self.sizer" being used (since "self" refers to the instance of, in your
case, the "MainFrame" class) but you never defined what "self.sizer" is
anywhere, so the interpreter is thinking, "What does he mean, self.sizer?
Where did he say self has this thing called sizer?"
If I may chip in - I also was confused by AttributeErrors early on (mostly
because Python was the first language where I actually "got" what object
orientation is all about!), but now I almost welcome them because... well,
if I'm going to make a mistake, at least it's an easy one to catch, right?
More to the point, though, this question seems to me like an excellent
demonstration of why generic-sounding variable names are a terrible idea.
I realize that you're working from someone else's code, but if he could
hear I would tell him too: DON'T name your sizers "sizer". Call them
MySizer, or Edger, or OuterBound, or... well, just about _anything_ that
doesn't make them sound like a built-in, generic property. This sort of
confusion - where a user-created attribute gets confused with a generic
property - happens all too often. The interpreter doesn't care at all what
you name your variables - so make them easy to identify, understand, and
remember.
I was confused by the tutorial scripts use of the name 'sizer;' there are
several such variable names in the scripts.
After moving from FORTRAN to C in the 1980s I learned to make variable
names meaningful to _me_. The compilers don't care. That's why, in the
fragments I posted, I use names such as:
# Sizers
outerBox = wx.BoxSizer(wx.VERTICAL) # main container
welcomeBox = wx.BoxSizer(wx.VERTICAL) # logo and message
unameBox = wx.BoxSizer(wx.HORIZONTAL) # username container
passwdBox = wx.BoxSizer(wx.HORIZONTAL) # password container
buttonBox = wx.BoxSizer(wx.HORIZONTAL) # OK and Cancel buttons
so I know what they do. When there are multiple layers of controls/widgets
within sizers within panels within a notebook within a frame my simple mind
likes to see variable names that are descriptive.
Thanks for your thoughts,
Rich
···
On Mon, 7 Jul 2014, Marc Tompkins wrote:
More to the point, though, this question seems to me like an excellent
demonstration of why generic-sounding variable names are a terrible idea.
I realize that you're working from someone else's code, but if he could
hear I would tell him too: DON'T name your sizers "sizer".
That's _half_ of what I was getting at... the other half is that sometimes
you need to write a generic helper function that works with (whatever sort
of object; a sizer in this case). It has to work with sizers from all over
your project - or projects in the future - so what do you call it? In
cases like that, my imagination sometimes fails me, and that's where
whimsical synonyms come in. I have several functions in my toolkit that
operate on a generic object... which I named "thingy". In the case of a
generic sizer, I have used "self.calibreur" on more than one occasion.
···
On Mon, Jul 7, 2014 at 5:09 PM, Rich Shepard <rshepard@appl-ecosys.com> wrote:
On Mon, 7 Jul 2014, Marc Tompkins wrote:
More to the point, though, this question seems to me like an excellent
demonstration of why generic-sounding variable names are a terrible idea.
I realize that you're working from someone else's code, but if he could
hear I would tell him too: DON'T name your sizers "sizer".
Marc,
I was confused by the tutorial scripts use of the name 'sizer;' there are
several such variable names in the scripts.
After moving from FORTRAN to C in the 1980s I learned to make variable
names meaningful to _me_. The compilers don't care. That's why, in the
fragments I posted, I use names such as:
# Sizers
outerBox = wx.BoxSizer(wx.VERTICAL) # main container
welcomeBox = wx.BoxSizer(wx.VERTICAL) # logo and message
unameBox = wx.BoxSizer(wx.HORIZONTAL) # username container
passwdBox = wx.BoxSizer(wx.HORIZONTAL) # password container
buttonBox = wx.BoxSizer(wx.HORIZONTAL) # OK and Cancel buttons
so I know what they do. When there are multiple layers of controls/widgets
within sizers within panels within a notebook within a frame my simple mind
likes to see variable names that are descriptive.
I am a fan of long variable names normally, but often with frames, panels, sizers, buttons, etc, that only last for about 4 lines of code, I may call them frm, pnl, szr, btn respectively. When the mood strikes me, I’ll use pseudo-Hungarian notation like Visual Basic programmers are known to use, e.g. szrOuter, btnUp, btnCloseFile, etc…
···
On Monday, July 7, 2014 7:59:10 PM UTC-4, Che M wrote:
More to the point, though, this question seems to me like an excellent demonstration of why generic-sounding variable names are a terrible idea. I realize that you’re working from someone else’s code, but if he could hear I would tell him too: DON’T name your sizers “sizer”. Call them MySizer, or Edger, or OuterBound, or… well, just about anything that doesn’t make them sound like a built-in, generic property. This sort of confusion - where a user-created attribute gets confused with a generic property - happens all too often. The interpreter doesn’t care at all what you name your variables - so make them easy to identify, understand, and remember.
That’s an excellent point, Marc! Naming a sizer “sizer” is just asking for trouble, particularly as a beginner, for exactly the reasons you give.
I am unashamedly a user of long inelegant object names, even to the point of backgroundSizerForMainFrame or textCtrlForTheUsersCookieRecipe. You are just not going to have an instant’s confusion when debugging as to what those objects are. (The less confused instants I have, the better. There are still many, though :\ ).
"szr", "pnl", etc. - excellent idea. It's still clear what sort of object
is referenced, but there's no danger of confusing it with a generic
attribute (as can happen with "sizer").
···
On Tue, Jul 8, 2014 at 2:29 PM, Rufus <rufusvsmith@gmail.com> wrote:
I am a fan of long variable names normally, but often with frames, panels,
sizers, buttons, etc, that only last for about 4 lines of code, I may call
them frm, pnl, szr, btn respectively. When the mood strikes me, I'll use
pseudo-Hungarian notation like Visual Basic programmers are known to use,
e.g. szrOuter, btnUp, btnCloseFile, etc...
This is a great example of the point I was making before... if the object
is only really manipulated *within that function*, then calling it pnl
might be fine (although I would still call it "panel"; abbreviations make
me twitchy), but if you have to access it from other functions or anywhere
elsewhere within the class, then the need to have clearer names is more. At
least IMHO.
···
On Tue, Jul 8, 2014 at 5:29 PM, Rufus <rufusvsmith@gmail.com> wrote:
On Monday, July 7, 2014 7:59:10 PM UTC-4, Che M wrote:
On Mon, Jul 7, 2014 at 7:53 PM, Marc Tompkins <marc.t...@gmail.com> >> wrote:
More to the point, though, this question seems to me like an excellent
demonstration of why generic-sounding variable names are a terrible idea.
I realize that you're working from someone else's code, but if he could
hear I would tell him too: DON'T name your sizers "sizer". Call them
MySizer, or Edger, or OuterBound, or... well, just about _anything_ that
doesn't make them sound like a built-in, generic property. This sort of
confusion - where a user-created attribute gets confused with a generic
property - happens all too often. The interpreter doesn't care at all what
you name your variables - so make them easy to identify, understand, and
remember.
That's an excellent point, Marc! Naming a sizer "sizer" is just asking
for trouble, particularly as a beginner, for exactly the reasons you give.
I am unashamedly a user of long inelegant object names, even to the point
of backgroundSizerForMainFrame or textCtrlForTheUsersCookieRecipe. You
are just not going to have an instant's confusion when debugging as to what
those objects are. (The less confused instants I have, the better. There
are still many, though :\ ).
I am a fan of long variable names normally, but often with frames, panels,
sizers, buttons, etc, that only last for about 4 lines of code, I may call
them frm, pnl, szr, btn respectively. When the mood strikes me, I'll use
pseudo-Hungarian notation like Visual Basic programmers are known to use,
e.g. szrOuter, btnUp, btnCloseFile, etc...
