fix(components): make all possible attributes private

[domire8]

Description

This PR improves the robustness of the Python component interfaces. It is possible that a user overwrites some of these attributes and completely breaks the components (for example self._period = 0.0 already completely breaks a components).

In this PR I made all possible attributes of components "private" and the necessary "protected" ones a bit more verbose to minimize chances of overriding. Two main disadvantages:

1. the lifecycle component now also needs to keep track of outputs, its kind of a duplicated dict but the only way to avoid having the _outputs "only protected"
2. A lot of the tests would have to disappear since they rely heavily on the fact that we can do stuff like assert "test" in component._outputs.keys()

What do you think? A valuable improvement or not?

Review guidelines

Estimated Time of Review: x minutes

Checklist before merging:

• Confirm that the relevant changelog(s) are up-to-date in case of any user-facing changes

[eeberhard]

Overall I think it's a reasonable change, but I don't really like the behavior of the lifecycle component to keep an associated map of outputs. It's quite confusing and that makes it seem brittle and hard to maintain.

the lifecycle component now also needs to keep track of outputs, its kind of a duplicated dict but the only way to avoid having the _outputs "only protected"

A lot of the tests would have to disappear

Not entirely true on both counts, as you could access them within LifecycleComponent as self._ComponentInterface__outputs, or from tests as my_component._ComponentInterface__outputs. The mangling of members with the double underscore (which we associate with a "private" visibility) is really just there to prevent accidental overriding or hiding of base members from derived classes. Using it functionally and intentionally in the library and in tests is not problematic at all in my opinion.

On a related note, some guides say not to unit test private anyway, only parts of the interface that can be accessed externally. I do generally agree with this when it comes to methods, but testing the value or state of private attributes such as __outputs is still reasonable to do in the test cases.

[domire8]

Thanks for your inputs, I made the necessary changes

[bpapaspyros]

Thanks @domire8 for the changes. I would also prefer private attributes, but I was skeptical of the outputs. I wasn't really aware of the python details. This seems nice now.