tl;dr I have a process that passes around a lot of state. Doing this instead of using the process dictionary affects coding design decisions. What would you do?

I have a project that passes around a lot of state. For example, this tracks the processing of an OpenAPI description as operations and schemas are discovered and named.

So far, I’ve followed the best practice of always passing this state around as arguments rather than using the process dictionary. It makes a few things awkward, like the occasional function that doesn’t need to know or update state except in rare circumstances, but must pass it through anyway. Because this project is meant to be pluggable for its consumers, I’ve made certain choices to avoid passing state in and out of callbacks in situations where a consumer is likely to mismanage the data. This has secondary effects for the project’s architecture which, although workable, reduce flexibility.

As the author, I can foresee and enforce that all of the processing will occur in a single process. I can also provide a suite of safe state management functions that discourage any manual editing of the data. The flexibility of always having the state available to read and write is alluring.

What would you do? Why? If you’re on the side of never use the Process Dictionary, can you imagine a circumstance where you would?