Thread: [myhdl-list] Signal getattr and setattr
Brought to you by:
jandecaluwe
Menu
▾
▴
myhdl-list
|
From: Christopher L. F. <chr...@gm...> - 2009-12-26 05:19:12
Attachments:
getattr.hg
|
Attached is a patch with some modification to __getattr__ and adds the __setattr__ in _Signal.py. I like the idea that the Signal class is "transparent". Meaning that the object that the Signal contains, its (the contained object) attributes and properties can be accessed. The change checks the "slots" before accessing the "objects" (self._val) attributes. The patch fixes the bug I previously posted, max recursion depth. I think I generated the bundle/patch correctly and tried to verify with a separate repository clone. The workspace I created the bundle from has additional changes (mainly error/warning statements and prints) that are not ready to be pushed. The only changes should be the couple lines in _Signal.py .chris |
|
From: Christopher L. F. <chr...@gm...> - 2009-12-27 22:29:25
|
Ignore the patch that was previously sent for now! I was careless and didn't run the regression tests. After running the "tests" it exposed some issues. It appears this method breaks the properties. Back to the drawing board. .chris Christopher L. Felton wrote: > Attached is a patch with some modification to __getattr__ and adds the > __setattr__ in _Signal.py. > > I like the idea that the Signal class is "transparent". Meaning that > the object that the Signal contains, its (the contained object) > attributes and properties can be accessed. > > The change checks the "slots" before accessing the "objects" (self._val) > attributes. > > The patch fixes the bug I previously posted, max recursion depth. > > I think I generated the bundle/patch correctly and tried to verify with > a separate repository clone. The workspace I created the bundle from > has additional changes (mainly error/warning statements and prints) that > are not ready to be pushed. The only changes should be the couple lines > in _Signal.py > > .chris > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > > > ------------------------------------------------------------------------ > > _______________________________________________ > myhdl-list mailing list > myh...@li... > https://lists.sourceforge.net/lists/listinfo/myhdl-list |
|
From: Jan D. <ja...@ja...> - 2009-12-27 22:46:08
|
Chris: I don't have a lot of time these days (moving to new house) but did your patch mean that __slots__ is the problem? I would hesitate a lot to apply a patch that customizes __setattr__, and that makes every attribute access slower. On the other hand, if __slots__ is the culprit, it would be one more argument to remove it. Explanations later. (Removing __slots__ shouldn't change signal behavior, but may break some unit tests also.) Jan Christopher L. Felton wrote: > Ignore the patch that was previously sent for now! I was careless and > didn't run the regression tests. After running the "tests" it exposed > some issues. It appears this method breaks the properties. > > Back to the drawing board. > > .chris > > Christopher L. Felton wrote: >> Attached is a patch with some modification to __getattr__ and adds the >> __setattr__ in _Signal.py. >> >> I like the idea that the Signal class is "transparent". Meaning that >> the object that the Signal contains, its (the contained object) >> attributes and properties can be accessed. >> >> The change checks the "slots" before accessing the "objects" (self._val) >> attributes. >> >> The patch fixes the bug I previously posted, max recursion depth. >> >> I think I generated the bundle/patch correctly and tried to verify with >> a separate repository clone. The workspace I created the bundle from >> has additional changes (mainly error/warning statements and prints) that >> are not ready to be pushed. The only changes should be the couple lines >> in _Signal.py >> >> .chris >> >> >> ------------------------------------------------------------------------ >> >> ------------------------------------------------------------------------------ >> This SF.Net email is sponsored by the Verizon Developer Community >> Take advantage of Verizon's best-in-class app development support >> A streamlined, 14 day to market process makes app distribution fast and easy >> Join now and get one step closer to millions of Verizon customers >> http://p.sf.net/sfu/verizon-dev2dev >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> myhdl-list mailing list >> myh...@li... >> https://lists.sourceforge.net/lists/listinfo/myhdl-list > > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Python as a HDL: http://www.myhdl.org VHDL development, the modern way: http://www.sigasi.com Analog design automation: http://www.mephisto-da.com World-class digital design: http://www.easics.com |
|
From: Christopher L. F. <chr...@gm...> - 2009-12-28 04:33:24
|
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. > > 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__? > > On the other hand, if __slots__ is the culprit, it would be one more > argument to remove it. Explanations later. > > (Removing __slots__ shouldn't change signal behavior, but may > break some unit tests also.) > > Jan > > > > Christopher L. Felton wrote: >> Ignore the patch that was previously sent for now! I was careless and >> didn't run the regression tests. After running the "tests" it exposed >> some issues. It appears this method breaks the properties. >> >> Back to the drawing board. >> >> .chris >> >> Christopher L. Felton wrote: >>> Attached is a patch with some modification to __getattr__ and adds the >>> __setattr__ in _Signal.py. >>> >>> I like the idea that the Signal class is "transparent". Meaning that >>> the object that the Signal contains, its (the contained object) >>> attributes and properties can be accessed. >>> >>> The change checks the "slots" before accessing the "objects" (self._val) >>> attributes. >>> >>> The patch fixes the bug I previously posted, max recursion depth. >>> >>> I think I generated the bundle/patch correctly and tried to verify with >>> a separate repository clone. The workspace I created the bundle from >>> has additional changes (mainly error/warning statements and prints) that >>> are not ready to be pushed. The only changes should be the couple lines >>> in _Signal.py >>> >>> .chris >>> >>> >>> ------------------------------------------------------------------------ >>> >>> ------------------------------------------------------------------------------ >>> This SF.Net email is sponsored by the Verizon Developer Community >>> Take advantage of Verizon's best-in-class app development support >>> A streamlined, 14 day to market process makes app distribution fast and easy >>> Join now and get one step closer to millions of Verizon customers >>> http://p.sf.net/sfu/verizon-dev2dev >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> myhdl-list mailing list >>> myh...@li... >>> https://lists.sourceforge.net/lists/listinfo/myhdl-list >> >> ------------------------------------------------------------------------------ >> This SF.Net email is sponsored by the Verizon Developer Community >> Take advantage of Verizon's best-in-class app development support >> A streamlined, 14 day to market process makes app distribution fast and easy >> Join now and get one step closer to millions of Verizon customers >> http://p.sf.net/sfu/verizon-dev2dev > > |
|
From: Jan D. <ja...@ja...> - 2010-01-13 17:46:27
|
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? >> 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. -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Python as a HDL: http://www.myhdl.org VHDL development, the modern way: http://www.sigasi.com Analog design automation: http://www.mephisto-da.com World-class digital design: http://www.easics.com |
|
From: Christopher L. F. <chr...@gm...> - 2010-01-17 03:04:38
|
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. > |
|
From: Jan D. <ja...@ja...> - 2010-01-18 08:41:46
|
Christopher L. Felton wrote: > 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. Then I think the proper way is for the copy functions to return Signal(self._init). -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Python as a HDL: http://www.myhdl.org VHDL development, the modern way: http://www.sigasi.com Analog design automation: http://www.mephisto-da.com World-class digital design: http://www.easics.com |
|
From: Jan D. <ja...@ja...> - 2010-01-18 08:41:49
|
Christopher L. Felton wrote: > 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 expect returning Signal(self._init) should do the trick. -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Python as a HDL: http://www.myhdl.org VHDL development, the modern way: http://www.sigasi.com Analog design automation: http://www.mephisto-da.com World-class digital design: http://www.easics.com |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X