Skip to content

Make classifications singleton#46

Merged
alanocallaghan merged 3 commits intoqupath:mainfrom
alanocallaghan:singleton-classifications
Oct 22, 2025
Merged

Make classifications singleton#46
alanocallaghan merged 3 commits intoqupath:mainfrom
alanocallaghan:singleton-classifications

Conversation

@alanocallaghan
Copy link
Contributor

@alanocallaghan alanocallaghan commented Oct 21, 2025

Change the method of caching in Classification to be on instance creation rather than with a separate method; this effectively enforces that sets of class names are unique. Therefore removes the get_cached method.

Adjust the equality test to ignore color and check for instance equality first (although caching in the constructor means that color should always be equal anyway, and values with the same name should still be equivalent).

Use names tuple directly as cache key.

Add some type checking to classification code, but massage the "obvious" inputs: bare str, list and tuple.

Removes name entirely, which is a mild inconvenience for getting a single string but should make the code more flexible.

I considered moving hidden attributes from single to double underscore to encourage name mangling, but apparently this is "not Pythonic" which makes me feel not very Pythonic

from qubalab.objects import Classification

class_a1 = Classification("a")
class_a2 = Classification("a")
class_a3 = Classification(["a"])
class_a4 = Classification(("a", ))

assert class_a1 is class_a2 and class_a2 is class_a3 and class_a3 is class_a4

class_ab1 = Classification("a: b")
class_ab2 = Classification(("a", "b"))
class_ab3 = Classification(("a", "b"))
class_ab4 = Classification(["a", "b"])

assert class_ab1 is not class_ab2 and class_ab2 is class_ab3 and class_ab3 is class_ab4

Related to discussions in #45 and #44; resolve #45

@petebankhead
Copy link
Member

From the description (I haven’t tried it or studied the code), I like the sound of all this.

I would be inclined to remove name entirely and eschew the joining on ": ".

Me too. I can’t think of a reason why we’d need it.

Can the tuple simply be used as the dict key instead?

@alanocallaghan
Copy link
Contributor Author

Yes I have that locally in the office, all it changes is the last assertion here no longer holds

@alanocallaghan alanocallaghan marked this pull request as ready for review October 22, 2025 09:28
@alanocallaghan
Copy link
Contributor Author

There was some discussion about whether we should drop Classification entirely and just use a tuple of names, but I think for now it is better to store the association between class and color in the objects.

Merging and I will test more thoroughly in my ongoing work with objects and measurements

@alanocallaghan alanocallaghan merged commit b198f57 into qupath:main Oct 22, 2025
3 checks passed
@alanocallaghan alanocallaghan deleted the singleton-classifications branch October 22, 2025 18:10
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.

Creating classifications and checking equality could be confusing

3 participants