Newbie Question regarding __init__()
dciphercomputing at gmail.com
Mon Aug 3 22:55:13 CEST 2009
On Aug 2, 5:51 am, Dave Angel <da... at ieee.org> wrote:
> Simon wrote:
> > Okay I will fix my code and include "self" and see what happens. I
> > know I tried that before and got another error which I suspect was
> > another newbie error.
> > The idea behind the init_Pre is that I can put custom code here to
> > customize the __init__ instead of creating a new subclass. This kind
> > of hook pattern allows you to flatten your inheritance hierarchy. I
> > can choose in the init_Pre method to execute code before the init_exec
> > (which contains the default __init__ code) and still execute the
> > init_Exec method or I can completely customize the entire __init__ by
> > returning False from init_Pre and prevent the init_Exec from being
> > called. I use this type of pattern with almost all my methods. In
> > this way I can create a less complicated inheritance chain but still
> > have have custom code when needed without sub-classing.
> > I am use to Visual FoxPro which where you can do
> > =is.init_Pre().And.This.init_Exec() and the result is discarded so
> > that is why it looks the way it does. In this form init_Exec has to
> > return a value. However, If self.init_Pre(): self.init_Exec() would
> > work the same and then I could avoid returning a value.
> > Thanks,
> > Simon
> > On Aug 1, 5:52 am, Dave Angel <da... at ieee.org> wrote:
> >> Nat Williams wrote:
> >>> As MRAB described, ALL instance methods need to accept 'self' as a first
> >>> parameter, as that will be passed to them implicitly when they are called.
> >>> This includes __init__. The name 'self' is just a commonly accepted
> >>> convention for the name of the instance object passed to methods. You don't
> >>> have to call it that, but you really should.
> >>> Take a look athttp://docs.python.org/tutorial/classes.html#class-objects
> >>> It might help shed some light on how methods and instances work.
> >>> One other thing. I'm a little confused by the first line of
> >>> dcObject.__init__:
> >>> self.init_Pre() and self.init_Exec()
> >>> I suspect this does not do what you think it does. init_Pre and init_Exec
> >>> will both be called by this expression (unless init_Pre throws an exception,
> >>> of course). You're not getting anything here that you wouldn't by just
> >>> calling each method on a separate line, except just making it harder to
> >>> read.
> >> Read the doc-string for init_Pre() and for init_Exec(). The final
> >> version of init_Pre() will return False in some circumstances, and in
> >> those circumstances Simon doesn't want init_Exec() to be called. He's
> >> deliberately using the short-circuit evaluation of 'and' to accomplish
> >> that.
> >>> On Fri, Jul 31, 2009 at 8:53 PM, Simon <dciphercomput... at gmail.com> wrote:
> >>>> Hi
> >>>> So should the dcObject class include the "self" as well since I have
> >>>> not defined an __init__ method in dcCursor?
> >>>> Simon
> >>>> --
> >> Every one of those methods in both of those classes need a "self" first
> >> argument. As others have said, all instance methods need a 'self.'
> (Please don't top-post. You should put new responses at the end of
> quoted text, or sometimes inline if that's clearer.)
> I don't understand your comparison to Foxpro. read on.
> As your code was last posted, you don't need a return value from
> init_Exec() Every function that doesn't have an explicit return will
> return None. And None is interpreted as False in an "and" expression.
> If you had an "if" around the whole thing, then you'd care.
All I meant by the FoxPro comment was the idea of using the equal sign
without a variable to throw away the result. Also in FoxPro there is
no such thing as automatically returning None. If there is no
explicit return then True is returned.
Thanks I did not know that None is interpreted as False.
More information about the Python-list