[Grok-dev] Re: Grok and database generations

[Leonardo Rochael Almeida]

Just be careful not to set mutable attributes in the class like this,
otherwise when you mutate the attribute, you'll be mutating an
attribute instance shared by the class with all instances.

You might also consider using properties for very tricky cases (e.g.
the mutable attribute case above), consulting an internal variable
that defaults to None and setting it to something else on first
access, which is a common idiom in OO languages.

Cheers, Leo

On 9/4/07, Sebastian Ware <sebastian at urbantalk.se> wrote:
> Excellent!
>
> I set my default attributes in the __init__ even when they aren't
> passed during instansiation. Adding them as class attributes sounds
> like a much better solution! This pattern would be great to use in
> sample apps.
>
> I agree, this is solution covers my usecase just fine. Further down
> the line, maybe an import/export component would be useful. :)
>
> Mvh Sebastian
>
>
> 4 sep 2007 kl. 18.40 skrev Philipp von Weitershausen:
>
> > Sebastian Ware wrote:
> >> I have been looking at the zope.app.generations package. For those
> >> who don't know about it, generations keeps track on your objects.
> >> The generations schema manager allows you to execute an evolve
> >> method in order to update objects to a required level of
> >> functionality. To determine which objects to update ituses a counter.
> >> However, my most usual use case is that I have added some new
> >> default values to the __init__ method of a class and I want to
> >> update all the objects of that class to reflect this change. But I
> >> want to do this without having to write any extra code. I just
> >> want to sync my objects...
> >> Is there any simple and smart way I could do this?
> >
> > Yup. It's called class attributes. When an instance doesn't have a
> > particular attribute, but a class does, the class attribute will be
> > used. When overwritten, it will be done so on the instance. For
> > example::
> >
> >   class Foo(object):
> >
> >       # make sure old instances also get this attribute
> >       attr = default_value_for_old_instances
> >
> >       def __init__(self, attr=some_default):
> >           self.attr = attr
> >
> > So if you have an instance of 'Foo' that was created before
> > __init__ set the 'attr' attribute, it will now be possible to say
> > 'foo_instance.attr' and it will resolve to
> > 'default_value_for_old_instances'.
> >
> >> If not, would this not be an excellent feature to add to Grok?
> >
> > For simple cases, I think defensive programming (e.g. gracefully
> > handling the absence of attributes) and tricks like I've shown
> > above work well enough that we don't need something special in Grok.
> >
> > *If* we have to introduce something to Grok, then it'll likely have
> > to handle trickier things as well. But tricky things are hard to do
> > in-place. They usually require good understanding of the way the
> > ZODB works. I think 'dump and reload' is much easier when you have
> > massive and/or tricky refactorings going on. As Tres says, it's not
> > a surprise that pretty much all RDBMS do it this way.
> >
> >
> > --
> > http://worldcookery.com -- Professional Zope documentation and
> > training
>
> _______________________________________________
> Grok-dev mailing list
> Grok-dev at zope.org
> http://mail.zope.org/mailman/listinfo/grok-dev
>