Newbie Question regarding __init__()

Simon dciphercomputing at
Mon Aug 3 22:55:13 CEST 2009

On Aug 2, 5:51 am, Dave Angel <da... at> 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> 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 at
> >>> 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> 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.
> DaveA

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 mailing list