-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Q: Initialization procedure #175
Comments
I do not remember anymore but there was a reason for this. |
From my subjective perspective it looks like 90% of the use cases do not need to do this. |
This should be OK. |
Well this will not change anything for anyone ;) I would add
This way change could actually happen. I can implement this easily if you want to test |
But of course this would break some stuff. My point is to design the API for the edge-cases is not the right approach. Can you tell me where you do something in between the initailization of the Dut and the init call? |
In general OK but not sure if this is a good idea to do now. Should accumulate more braking changes? |
Maybe not best example: https://gitlab.cern.ch/silab/bdaq53/-/blob/development/bdaq53/system/bdaq53.py |
The only line where something happens in between initialization and manual call to |
But yes, maybe we can wait and have a more thorough look at this, maybe accumulate other braking changes. |
Just to add, since tj-monopix2-daq is almost exactly like bdaq, this will also be affected. No problem for me to adapt, though. |
Is there a particular reason for the following syntax to be necessary?
Why not call
my_device.init
inside the instances__init__
?The text was updated successfully, but these errors were encountered: