Re: [pygame] GUI Frames and classmethod

[shandy@geeky.net]

Hi Zak.

Personally, I would recommend the Factory design pattern.  So you would
just make a FrameFactory class and instead of normally constructing Frame,
you'd use the factory.

battleFrame = myFrameFactory.newFrame( BattleFrame )

There is another option I thought of, but I actually recommend against
this, as it requires a lot of knowledge about python and is more difficult
to read and opens the door for a lot of errors.

But it's so damn cute:

class Foo:
    def __getattr__(self, name):
      print "in dict?", (name in self.__dict__.keys())

      if (name in self.__dict__.keys()):
        print "callable?", callable(self.__dict__[name])
        return self.__dict__[name]

      else:
              print "you requested an attribute that i don't have"
              #let's construct a default handler here
              # you could check here that it corresponds to some known
              # format
              # so that you don't make handler functions for EVERY typo
              return self.handlerFunctionClosure(name)

    def go(self):
      print "i am SO going"

    def handlerFunctionClosure(self, methodName):
        # define the handler function in this scope to dynamically generate
        # the handler functions.  You could also just return a method that
        # you'd create in the class scope
        def handlerFunction(*args,**kwargs):
                print "Hi, I'm the handler function"
                print methodName,args,kwargs    # do what you want to here
        return handlerFunction


This basically detects if you've called a method or attribute that doesn't
exist.  If so, it creates a function (handlerFunction) and runs that
instead.

But yeah, it's also evil.

-sjbrown


> My question: What are Pythonic alternatives to this sort of thing?
>
> I can think of a few solutions, but none of them seem to be obviously
> advantageous:
>
> 1. All children don't call __init__, but have an _init() method that
> is called by Frame.__init__(). That way ButtonFrame has an _init()
> method rather than an __init__() method. This may be my best option.
> ###
> class Frame:
>     def __init__(self, owner, pos, size=None):
>         self.owner = owner
>         self.children = []
>         # more setup code here.
>
>         self._init()
>
>         self.create_empty_state_methods()
> ###
>
> 2. Frame has an init() function that needs to be called following the
> instantiation of a Frame (or Frame child object). I'm not too keen on
> this, because it requires creating the Frame object and _then_ running
> an init() method. I try to keep that sort of thing to a minimum
> because it makes quick object creation a little funky. (init() has to
> return self so you can do a myList.append(ButtonFrame().init()))
> ###
> class Frame:
>     def __init__(self, owner, pos, size=None):
>         self.owner = owner
>         self.children = []
>         # more setup code here.
>
>     def init(self):
>         self.create_empty_state_methods()
>         return self
>
> b = Frame()
> b.init()
> myList.append(b)
> ###
>
> Phew! Hope that's not overly long! Now I can't be the first person to
> want a pre- and post- child init code! I'm worried that I'm
> overlooking something or there's an even more Pythonic way to do
> things than above.
>
> --
> Zak Arntson
> http://www.harlekin-maus.com - Games - Lots of 'em
>


----
Sent from geeky.net