Classes, OOP, Tkinter general comments and detailed questions...

Alex Martelli aleaxit at yahoo.com
Thu Apr 12 11:31:22 EDT 2001


"Alan Gauld" <alan.gauld at bt.com> wrote in message
news:3AD5C725.33693D16 at bt.com...
    [snip]
> > for the next one -- that (in my experience) makes event-driven
> > processing nowhere as hard to learn, master _and_ use productively
> > as interrupt-driven programming
>
> Yes, but if you know interrupt programming - as an assembler
> programmer might - then event driven is a piece of cake once you
> realize its the same conceptual model :-)

True -- if you know how to handle a harder problem, realizing
that an easier one falls into similar patterns helps a lot.


> >  you are still thinking about ONE path
> > of execution, albeit split up into not-too-big chunks.
>
> Only within an event handler, the flow of control across
> a use-case say is still fragmented and several use-cases
> may be executing simultaneously. Thus all of the context
> saving issues still apply - and for that OO makes it sooooo
> much easier :-)

An excellent point about "granularity" in use-case terms.
And, yes, natural places for stashing all of the state away
do come in handy indeed.


Alex






More information about the Python-list mailing list