[FEATURE] The ability to extend ModelInputType, Language, etc...

[workforcedeveloper]

Problem

Is your proposal tackling an existing problem or limitation?

• Yes, the problem is that when I am building tasks and want to add additional languages or model input types but can't because I can't monkey-patch additions because they're enums. Take for instance the following code:

from workrb.types import Language

class AfricanLanguages(Language):
    SW = "sw"

This code doesn't work because Language is an enum.

For example, when looking at the function signatures of the base classification tasks and base ranking tasks:

@abstractmethod
    def input_type(self) -> ModelInputType:
        """Input type for texts in the classification task."""

it's required for the return type to be a ModelInputType, but there's no way to add additional ModelInputTypes or Languages.

Proposal

Describe what you would like to see happen.

Open to other ideas, but my immediate thought is to simply remove the Enum from types so that individuals can then extend the enum classes and add an additional feature.

• Type:

  • New Ontology (data source for multiple tasks)
  • New Task(s)
  • New Model(s)
  • New Metric(s)
  • Other

• Area(s) of code: paths, modules, or APIs you expect to touch

Alternatives

Have you considered other approaches? Briefly list them and why you did not choose them.

Additional Context

Links to related issues, PRs, docs, or external references.
Screenshots or small examples if useful.

Implementation

• I plan to implement this in a PR
• I am proposing the idea and would like someone else to pick it up

[warreveys]

Good catch, this is a real limitation.

Two problems I have in mind with dropping the Enum though. First, subclassing wouldn't give you what you want even if it were allowed: AfricanLanguages.SW lives in its own namespace, so core code calling Language(x) still wouldn't find it, and every task, dataset ID, and result key goes through that lookup. Second, we rely on the enum raising ValueError on unknown codes, that's what catches a typo like languages=["deu"] and what drives the "override get_dataset_languages" error. Plain string constants would let bad codes flow silently into dataset IDs and result keys, and "en" / "EN" / "eng" would become three separate rows in the aggregated results.

What I'd suggest instead: keep the enums closed as they are, but let people add members at runtime. Enum has a hook for exactly this, _missing_, which is called when a lookup fails. So you keep a module-level registry of extra codes, and _missing_ checks it before giving up:

class Language(str, Enum):
    EN = "en"
    ...

    @classmethod
    def register(cls, code: str) -> "Language":
        """Register a language code not shipped with WorkRB."""
        # add to registry, create and return the pseudo-member

    @classmethod
    def _missing_(cls, value):
        # return the registered member for `value`, or None to raise as usual

Usage is then a single call at import time:

Language.register("sw")
MyTask(languages=["sw"])

The nice part for this is that nothing else has to change: every existing Language("sw") call site starts working, unregistered codes still raise, .value still serializes to a clean string, and no type annotation in the library moves. It's all contained in types.py. Main wrinkle to be deliberate about is that the registry is global mutable state, and registered members won't show up in list(Language) unless you handle that too.

Do you think this covers your use case?