[ENH] should `get_tag` and `get_class_tag` be merged into a single method?

[fkiraly]

API design discussion on whether, ultimately, we should endeavour to merge get_tag and get_class_tag into a single method. Similarly, get_tags and get_class_tags.

Currently, the two methods are mostly complementary, doing the same thing for classes vs instances. On classes, get_class_tag has to be called, and get_tag will fail. On instances, get_tag has to be called, and get_class_tag will work - retrieving the default/base setting of the tag, as opposed to dynamically set tags.

If we would merge the method, some redundancy would be removed, but it would no longer be programmatically possible to retrieve the base setting via get_class_tag - except if we add another parameter.

We could also leave get_class_tag while routing get_tag calls to get_class_tag for classes, but that might violate python zen.

An experimental, illustrative PR can be found here: #560

[yash-sangwan]

Hi @fkiraly! I've been looking into how we could merge get_tag and get_class_tag, and wanted to share an approach before I go further with it.

The main tricky part is keeping dynamic instance tags working properly. A plain @classmethod doesn't seem enough here, when it's called on an instance, we lose access to self._tags_dynamic, so tags set through set_tags/clone_tags would quietly stop working.

The cleanest approach I found is using a small custom descriptor (basically a "hybrid method" overriding __get__). That way, a single get_tag can detect whether it was called on the class (obj is None) or on an instance, and then route to the right logic. It also gives a good place to handle the different raise_error defaults both methods currently use.

A couple things I noticed that we should probably be careful about:

1. I don't think we can fully remove get_class_tag.
   Some core places - _dependencies.py and _lookup.py, intentionally call get_class_tag on instances to bypass dynamic tags and read the inherited static value instead. If everything goes through get_tag, those calls would suddenly start picking up overridden dynamic values, which could change behaviour silently. So I think keeping get_class_tag as a static-only path probably still makes sense (maybe deprecated later if needed).

2. This could also simplify TagAliaserMixin.
   Right now the alias-resolution logic is duplicated between the class and instance methods, so while touching this area we could probably move that into one shared helper.

If this sounds reasonable, I'll open a small proof of concept PR so we can see how it behaves in downstream CI.

[fkiraly]

I think the key problem is exactly 1 - if we merge the methods, then it is unclear how to get the originally inherited tags, design-wise. If you keep a second method for this purpose, then you end up with the current, two-method situation.

So the question is perhaps, does it bring any benefit to make get_tag function on classes, with the same return as get_class_tag. The benefits of this seem marginal.

Either way, a prototype already exists in #560 - though I do not think the best use of your time is this (currently a bit esoteric) topic.