Performance benchmarks:

I know there was an idea of using an enum in the fixme, but this can also be handled via Literal[] type hinting. What are the merits of both approaches and why would you argue that enums are better? Moreover, as indicated in the FIXME, there is a lot more going on here that might not be doable with a simple enum (hence the fixme comment).

@quaquel Here's my comparison of both approaches:

Literal[] Pros

• Zero runtime overhead
• Purely static, no new classes

Literal[] Cons

• No runtime validation (typos pass silently at runtime)
• No discoverability (list(SignalType) not possible)
• Limited IDE support compared to enums
• Cannot be extended by subclasses

Enum Pros

• Runtime validation catches errors
• Full IDE autocomplete and discoverability
• SignalType(str, Enum) has no overhead (inherits from str)
• Extensible: subclasses can add domain-specific signals
• Introspectable: list(SignalType) works

Regarding the Broader FIXME

"Ideally you can define signal_types throughout the class hierarchy and they are just combined together"

This actually favors enums because:

1. Custom enums can inherit/extend SignalType
2. Subclasses like ObservableList could define:

   class ListSignalType(SignalType):
       APPEND = "append"
       REMOVE = "remove"

No runtime validation (typos pass silently at runtime)

I don't think this is correct. HasObservables.observe raises a value error if you try to subscribe to a signal type that is not being emitted by the observable.

Limited IDE support compared to enums

I mostly agree, although support for typing and, by extension, Literal is improving rapidly in most IDEs.

Extensible: subclasses can add domain-specific signals
Introspectable: list(SignalType) works

I am not entirely sure how subclassing Enums works, so I would need an example or some time to investigate this myself. However, ideally, it should be trivial to obtain an overview of all observables and, for each observable, the signals it can emit.

@quaquel

Runtime validation:
You're right - I should have been more precise. HasObservables.observe does validate at runtime, but only when you call observe(). The issue is that typos in signal names passed to emit() or when checking if signal_type in ... won't be caught unless there's an active observer. With enums, typos are caught immediately at parse time by the IDE and at runtime whenever the enum is referenced.

Extensibility and introspection:
For enum subclassing, here's an example:

from enum import Enum

class BaseSignals(str, Enum):
    CHANGED = "changed"
    REMOVED = "removed"

class CellSignals(BaseSignals):
    AGENT_ADDED = "agent_added"
    AGENT_REMOVED = "agent_removed"

# Works with type checkers
def handle_signal(signal: CellSignals): ...

# Introspection
list(CellSignals)  # All signals including inherited ones
BaseSignals.CHANGED in CellSignals  # True

Thanks. I'll try to take a quick look myself later today at your example as well as reacquaint myself with this code to see if enums indeed solve all issues I had in mind when I wrote the fixme.

Sure got it.

As a further exploration of this idea, could you also update observable_collections? Here, more signals exist, so it's a nice test to see if using enums works as intended.

As a further exploration of this idea, could you also update observable_collections? Here, more signals exist, so it's a nice test to see if using enums works as intended.

Sure I will update it.

@quaquel I have updated the observable_collections also with enum.