Performance benchmarks:

One thing that I’ve been encountering while actually building stuff with both this and events, is that control over the order becomes more difficult. You need to keep carefully keep track of priorities with events. For signals, how can you currently determine the order of execution if multiple things subscribe to the same signal?

The previous data collection stuff we just setup at the end of the init. I assume here is the problem that there’s user init code executed after that? Can/need we to wrap the user init? Or add a post init?

edit: I thought we discussed something like this at some point, just found it:

• Stop overriding `Model.__init__()` in user models, use a `setup` method instead #2354

One thing that I’ve been encountering while actually building stuff with both this and events, is that control over the order becomes more difficult. You need to keep carefully keep track of priorities with events. For signals, how can you currently determine the order of execution if multiple things subscribe to the same signal?

Both events and signals are first-in in first-out. Of course, with events, you have priority to further control this. For signals, you don't have priorities.

The previous data collection stuff we just setup at the end of the init. I assume here is the problem that there’s user init code executed after that? Can/need we to wrap the user init? Or add a post init?

The problem is that with the old collection, the user explicitly has to call collect. With the new stuff, we aim for a fully reactive design. So, in #3145, after initializing the DataRecorder, it wants to collect immediately if the first collect is on t=0. But of course, this forces the user to initialize the recorder at the end of the __init__. Which is not a nice design.

There is no __post_init__ for normal Python classes. Yes, you can do various things using __init_subclass__, but in my view, this solution is simpler. It also is a bit of a stopgap solution. For Mesa 4, we really should add a RunConfiguration class that at a minimum specifies start_time and end_time, but which might be extended to include datetime and calendar information.

Performance benchmarks:

So what if somebody wants to check self.time before the first run is called?

So what if somebody wants to check self.time before the first run is called?

It just returns 0.0, because in the __init__ I set the private variable of the observable to 0.0.

Just to clarify. An Observable is a descriptor. A common pattern in descriptors is to have the __get__ tied to a name (e.g., time) and use an internal private variable (typically _{public_name}, so _time) for storage. I exploit that here by setting the private variable explicitly in model.__init__. Any __get__ on model.time afterwards will just return the value of the private variable (so. 0.0). Once we start running, we explicitly do model.time = 0.0, which emits an ObservableSignals.CHANGED signal and sets the private variable (again) to 0.0.

This PR is a somewhat convoluted way to emit a signal indicating that the run has started without having to add new signals. For mesa 4, I want to add RunControlSignals like RUN_STARTED, RUN_STOPPED, and RUN_ENDED. But this requires the TIME api to be further fleshed out on the condition side, likely a RunConfiguration class, and perhaps some other things. For 3.5, and the further development of the new data collection, this solution is good enough.

Thanks for explaining. Are our observables build in such a way that they always (and automatically) have a private variable with the exact same name but with an underscore? If not, where does that assignment happen?

Are our observables build in such a way that they always (and automatically) have a private variable with the exact same name but with an underscore? I

yes.