How to instantiate in a lazy way?

[Slaunger]

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

> >                  I1, Q1, I2, Q2 = bytes_to_data(buf)
> >                  self.__dict__["I1"] = I1
> >                  self.__dict__["Q1"] = Q1
> >                  self.__dict__["I2"] = I2
> >                  self.__dict__["Q2"] = Q2
> >                  return self.__dict__[attr_name]
>
> I think you want setattr() here - __dict__ is an implemetation detail
> - classes with __slots__ for instance don't have a __dict__.  I'd
> probably do this

Oh my, I did not know that. __slots__?? Something new I got to
understand.
But you are right. thanks!

>
>                    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 would probably factor out the contents of the if statement into a
> seperate method, but that is a matter of taste!

Agreed. I thought about that myself for better code readability.

As a final comment, I have actually refacted the code quite a bit
as I have to do this ...OnDemand trick for several classes, which have
different data attributes with different names.

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

I guess this somewhat resembles the decorator approach - I just could
not figure out
how to kake a general purpose decorator.

For this to actually work the "instant" PayloadBaconAndEggs class
simply has to define
and implement a few class attributes and static utility functions for
the unpacking.

-- Slaunger