How to instantiate in a lazy way?

[Slaunger]

On 3 Dec., 15:30, Nick Craig-Wood <n... at craig-wood.com> wrote:
> Slaunger <Slaun... at gmail.com> wrote:
> >  On 3 Dec., 11:30, Nick Craig-Wood <n... at craig-wood.com> wrote:
> > > > ? ? ? ? ?cls = self.__class__
> > > > ? ? ? ? ?if attr_name in cls.data_attr_names:
>
> > > self.data_attr_names should do instead of cls.data_attr_names unless
> > > you are overriding it in the instance (which you don't appear to be).
>
> >  Yeah, I know. I just like the cls notation for code readability
> >  because it tells you that it is a class attribute, which is not
> >  instance- dependent.
>
> >  That may be legacy from my Java past, where I used to do it that
> >  way.  I know perfectly well that self. would do it. i just find
> >  that notation a little misleading
>
> I quite like it... It looks in the instance, then in the class which I
> find to be very elegant - you can set a default in the class and
> override it on a per object or per subclass basis.
>
In principle yes.

In the particular case in which it is used I happen to know that it
would not make sense to have a different attribute at the instance
level.

That is, however quite hard to realize for outside reviewers based on
the small snippets I have revealed here. So, i certainly understand
your view point.

The cls notation sort of emphasizes that instances are not supposed to
override it (for me at least), and if they did, it would be ignored.
In other applications, I would use self. too.


>
> > > ? ? ? ? ? ? ? ? ? ?for k, v in zip(("I1", "Q1", "I2", "Q2"), bytes_to_data(buf)):
> > > ? ? ? ? ? ? ? ? ? ? ? ?setattr(self, k, v)
> > > ? ? ? ? ? ? ? ? ? ?return object.__getattr__(self, attr_name)
>
> >  And perhaps even more readable (how I do it now, no need to call
> >  __getattr__ for an attribute, whcih is already there):
> >                  ...
> >                  for attr, value in zip(cls.data_attr_names,
> >  bytes_to_data(buf)):
> >                      setattr(self, attr, value)
>
> >                  return getattr(self, attr_name)
>
> I wrote the object.__getattr__ call to stop recursion troubles.  If
> you are sure you've set the attribute then plain getattr() is OK I
> guess...

Ah, Ok. I am sure and my unit tests verify my assurance.
>
> >  In this process I have actaully managed to isolate all the
> >  ...OnDemand stuff in an abstract PayloadOnDemand class
>
> >  I can now use this "decorator-like"/helper class to very easily
> >  make an ...OnDemand variant of a class by just doing multiple
> >  inheritance - no implementation:
>
> >  class PayloadBaconAndEggsOnDemand(PayloadOnDemand, PayloadBaconAndEggs): pass
>
> You've reinvented a Mixin class!
>
>  http://en.wikipedia.org/wiki/Mixin
>
> It is a good technique.
>

Wow, there is a name for it! It did not know that.

Hmm... I never really took the time to study those GoF design
patterns.

(I am a physicist after all... and really a programmer)

I guess I could save a lot of time constantly re-inventing the wheel.

Are there any good design pattern books focused on applications in
Python?
(Actually, I will post that question in a separate thread)

Once again, I am extremely pleased with your very thoughtful comments,
Nick. Thanks!

-- Slaunger