Best practice for object attributes?

[Mike C. Fletcher]

Just... can't... resist... question... on... modelling... domain... 
objects...

class Shrubbery1( propertied.Propertied ):
    """Representation of a Shrub, surprisingly"""
    name = common.StringProperty(
       "name", """The name of the intrepid gardener""",
       defaultValue = "",
    )
    flowering = common.BooleanProperty(
       "flowering", """Whether this is carniverous flowering Blood Root""",
       defaultValue = 0,
    )
    knightOwner = basic.BasicProperty(
       "knightOwner", """The knight which own the shrub's mortgage""",
       baseType = Knight,
       # stupid example, just asks the Knight type for default instance
       # probably looking up who owns the plot of land on which we sit
       defaultFunction = lambda prop, client: 
Knight.getDefaultKnight(client),
       setDefaultOnGet = 0, # until explicitly assigned, will always 
lookup the default
    )

Wendal = Shrubbery1( name = "Wendal", knightOwner = SirHenry )
Grace = Shrubbery1( name = "Grace" )
# Grace's knightOwner is now getDefaultKnight(Grace) at the time you ask 
for it

The advantages of this way being:

    * GUIs can introspect the property to figure out all sorts of
      wonderful things, such as how to coerce values to the correct
      types, or what type of "selection" widgets to show for "knightOwner"
    * The properties show up in your standard pydoc documentation
      (though admitedly, only the __doc__ values are useful in that case)
    * You can define functions for retrieving the defaults, so that
      run-time lookups occur to figure out who is the current default despot

Of course, then you need the basicproperty package, but doesn't 
_everybody_ want that? ;)

See also:

    * Chaco's Traits library (including delegation)
    * Zope 3's Field objects (deep in the bowels of Zope, (with cool
      little "bootstrap fields" describing them))
    * OpenGLContext's vrml fields library (sub-domain specific (i.e. 3D
      graphics))

(I intuit the existence of a few others (A.B.Strakt's, the Chandler 
people's), but they aren't available yet AFAIK)

Enjoy,
Mike  

Michael Sparks wrote:

>Hello,
>
>
>If I want to model objects with 3 attributes based on the behaviour of
>python 2.2/2.3 I'ved noticed I can use either of the following idioms:
>
>class shrubbery1(object):
>   name = None
>   knightowner = "ni"
>   flowering = False
>
>or:
>class shrubbery2(object):
>   def __init__(self):
>      self.name = None
>      self.knightowner = "ni"
>      self.flowering = False
>
>In both cases I gain objects which have the same 3 attributes.
>Differences between
>them I find are:
>   * shrubbery1 has 3 class attributes as well, with the initial values
>     indicated. This isn't the case with shrubbery2.
>
>     >>> [x for x in dir(shrubbery1) if not x[0] == "_"]
>     ['flowering', 'knightowner', 'name']
>
>     >>> [x for x in dir(shrubbery2) if not x[0] == "_"]
>     []
>
>   * shrubbery2 has 3 entries added to self.__dict__ which act as the
>     attribute stores. This is not the case with shrubbery1.
>
>     >>> shrubbery1().__dict__
>     {}
>     >>> shrubbery2().__dict__
>     {'flowering': False, 'name': None, 'knightowner': 'ni'}
>
>
>Personally I find the former (shrubbery1) clearer, but I'm posting to
>find out what people think is generally the better of the two. Do people
>find any inherent advantages to one versus the other? (I note that the
>shrubbery1 also makes the names of object attributes available to
>metaclasses as well)
>
>Thanks for any comments,
>
>
>Michael.
>  
>
_______________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://members.rogers.com/mcfletch/