Re: [myhdl-list] Signal getattr and setattr

[Christopher L. F. <chr...@gm...>]

Jan Decaluwe wrote:
> Christopher L. Felton wrote:
>> Jan Decaluwe wrote:
>>> Chris:
>>>
>>> I don't have a lot of time these days (moving to new house) but
>> No problem, this is not a bug often encountered and I have a work around 
>> for accessing the "contained" objects attributes/properties.  Enjoy 
>> moving to the new house!
>>
>>> did your patch mean that __slots__ is the problem?
>> I don't believe __slots__ is the problem.  And you do get the 
>> performance increase from __slots__ but I don't know how much.
>>
>> I believe the issue is how the copy works.  The copy tries to access 
>> variables before they exist?  I don't know the exact mechanism of the 
>> copy but that appears to be the issue.
>>
>> By adding an attribute read in __init__ before it is set, a similar 
>> failure occurs.  Example first line of __init__ print self._val.
>>
>> At this point two options would be remove __getattr__ or add __copy__ 
>> and __deepcopy__ to return a new instance and set attributes manually.
> 
> That seems the good solution.
> 
> Of course, how easy it is depends on what "copying" means. The way I
> think about it, it seems trivial: simply create a new signal with the
> same initial value. This would create a new signal that, in the same
> context, would behave identically to the original, but with for the
> rest all separate data structures internally.
> 
> That is what a "copy" is to me, but what about your application?

Yes, copy to me means the same.  Same as the copy implementations in 
intbv?  Adding the __copy__ and __deepcopy__ makes sense otherwise it is 
passed to the "val" copy implementation.

> 
>>> I would hesitate a lot to apply a patch that customizes __setattr__,
>>> and that makes every attribute access slower.
>> That is a good point, performance impact.  I do like the idea of a 
>> "transparent" Signal object but it is not looking to feasible.  But if 
>> the setattr isn't  propagated to the "contained" object does it make 
>> sense to allow __getattr__?
> 
> Like always, reading an writing are not symmetrical, with reading
> being the easy case :-) Using __getatrr__ to delegate attribute access to
> the current value is exactly how I think a signal should work
> intuitively. It also does what you expect: it only comes into play
> for attributes that don't exist already. But that is not true for
> __setattr__: once it exists, you have to use it for any attribute
> access, which may be tricky and counterintuitive.
>