Add Handler.initialise(controller)

[ajgdls]

Resolves #59
Added default initialise methods to Sender and Updater base classes.
Added initialise method to Attribute, checks for handler and calls the method.
Moved initialise into BaseController class, loops over attributes calling initialise with a reference to self.
Added unit test for Attribute class.

Fixes #59
Fixes #130

[codecov]

Codecov Report

Attention: Patch coverage is 94.23077% with 3 lines in your changes missing coverage. Please review.

Project coverage is 90.81%. Comparing base (6a8c649) to head (d52f300).
Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
src/fastcs/controller.py	84.61%	2 Missing ⚠️
src/fastcs/backend.py	94.44%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #135      +/-   ##
==========================================
- Coverage   90.83%   90.81%   -0.03%     
==========================================
  Files          41       41              
  Lines        1954     1971      +17     
==========================================
+ Hits         1775     1790      +15     
- Misses        179      181       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[jsouter]

Could be helpful for setting up things like converters so we can have less logic inside the update/put calls!

[evvaaaa]

I think as part of this change we should take out controller as an argument to put/update, making this PR unneccesary.

If the user wants the controller in the handler for use in put or update then they should store it as an attribute (in the python sense) in their handler from initialise.

We can take out controller as an argument here

FastCS/src/fastcs/backend.py

Lines 76 to 87 in 5aa7a12

	def _link_attribute_sender_class(
	controller_api: ControllerAPI, controller: Controller
	) -> None:
	for attr_name, attribute in controller_api.attributes.items():
	match attribute:
	case AttrW(sender=Sender()):
	assert not attribute.has_process_callback(), (
	f"Cannot assign both put method and Sender object to {attr_name}"
	)
	callback = _create_sender_callback(attribute, controller)
	attribute.add_process_callback(callback)

and here

FastCS/src/fastcs/backend.py

Lines 130 to 141 in 5aa7a12

	def _create_updater_callback(attribute, controller):
	async def callback():
	try:
	await attribute.updater.update(controller, attribute)
	except Exception as e:
	print(
	f"Update loop in {attribute.updater} stopped:\n"
	f"{e.__class__.__name__}: {e}"
	)
	raise
	return callback

@GDYendell

[GDYendell]

This is actually broken and is showing up a lack of testing. The updater callbacks are still being called with a controller here, which causes them to stop and print a warning.

The reason this exception is caught and printed was originally so that one attribute update failing doesn't crash the whole application. I was on the fence about this and am again thinking just crashing would be better.

Although to be fair if this had type hints that would have caught it.

[ajgdls]

Good spot, I guess you noticed this by running an application? Perhaps I should add the type hints as this is not really a runtime exception but a develop time syntax error.

Resolved