Easier access to metadata and other features of properties/actions#258
Open
Easier access to metadata and other features of properties/actions#258
Conversation
This adds a new class that provides access to the useful methods of a BaseDescriptor, without needing to retrieve the BaseDescriptor object directly. This should tidy up code in a few places, where we want to refer to the affordances directly, not just their values.
This commit creates a new class, `BaseDescriptorInfo`. The intention is that using `BaseDescriptorInfo` will be more convenient than passing around descriptors. It may also be bound to an object, which should be significantly more convenient when both a Thing instance and a descriptor need to be referenced. An important side-effect that I'll note here is that `BaseDescriptor` is now a *Data Descriptor* as it implements a `__set__` method. This is arguably the way it should always have been, and simply means that `BaseDescriptor` instances won't get overwritten by the instance dictionary. Making `BaseDescriptor` instances read-only data descriptors by default means I can get rid of a dummy `__set__` method from `ThingSlot`.
This introduces the `DescriptorInfoCollection` class, and a descriptor to return it. The `DescriptorInfoCollection` is a mapping that returns `DescriptorInfo` objects. This makes it convenient to obtain both bound and unbound `DescriptorInfo` objects.
This includes tests for `PropertyInfo` and a fix to handle access to missing fields correctly. `.Thing.properties[<name>]` now returns a `PropertyInfo` object allowing access to the property's metadata. `.Thing.settings` does the same for settings, and also builds a model for loading/saving the settings. It does not, yet, load/save them, and needs test code.
This now means that a test for `isinstance(obj, self.value_type)` works as expected. I've added the descriptor name to a couple of error messages, for clarity, and improved docstrings to satisfy flake8.
This commit makes use of the new `Thing.settings` to generate a model for the settings file, and load/save the settings using a model. This has two advantages: * Settings that are typed as a model are now correctly loaded as a model. * Settings with constraints are validated when the settings file is loaded. The first point should get rid of some unnecessary code downstream. The second point is related to a change in behaviour: broken or invalid settings files, including those that have extra keys in them, now cause an error and will stop the server from loading.
This was accidentally defined on PropertyInfo, when it should have been in SettingInfo.
This is added, largely for completeness so it's consistent between actions, properties and settings.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Currently, Actions and Properties are implemented through Descriptor classes. These are hard to interact with directly: in the case of a property, we can get and set it nicely by getting/setting the attribute of the
Thing, but accessing anything else is inelegant:This merge request adds some mapping properties to a
.Thingthat allow:and so on. This will clean up LabThings code in a few places, and I think it also has the potential to make downstream code more readable, particularly when describing a UI or doing things like resetting properties to their default values.
There's a fair bit of additional code, but I think the majority of it is quite straightforward.
The most noticeable change in behaviour is that
Thing.settings.modelis now available, which allows us to load/save settings using aBaseModelthat means we no longer need settings to accept dictionaries when they are typed asBaseModelsubclasses.