Skip to content

Conversation

@rwb27
Copy link
Collaborator

@rwb27 rwb27 commented Feb 3, 2026

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 .Thing that allow:

self.properties["foo"].observe()
self.actions["increment_foo"].title

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.model is now available, which allows us to load/save settings using a BaseModel that means we no longer need settings to accept dictionaries when they are typed as BaseModel subclasses.

rwb27 added 8 commits January 31, 2026 08:53
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants