This issue is not related to recomputing – it’s related to modifying the only instance of the dictionary that you create, but doing so more downstrams, and observing the results of the same computation on the modified dictionary.
When you use Grasshopper types, GH will create copies of objects for you before they are passed to scripting components. Because we create here our types ourselves, these will just be passed as a reference. All non-Grasshopper types are unknown to Grasshopper, so it does not know how to copy them. You need to copy them yourself, or you can keep inputs unchanged and work only on outputs.
A simple way to avoid this, would be to just use
copy, a specialized Python module, and make a deep copy of the dictionary before modifying it. A more elegant way would be not to touch the input dictionary, and make changes only on a new data set. To help with this option, you could use a read-only (immutable) type, for example frozenset or tuples and other immutable types. This would prevent accidental modifications downstream.
Also, as a minor comment, it seems that the concept of dictionary is not used sparingly where it’s required here, but has become very pervasive, to the detriment of readability. Dictionaries are meant to be used for particular lookup problems, especially because they are heavy on memory, but also a little difficult/big in implementation and with some problem in behavior where there are many hash collisions. Here, where the
word_id is just an increasing integer, this really could just be a list. Again, nothing prohibits you from doing it this way.
avail_wordSize etc could also just be attributes in a class. My 2 cents.
copy-issues.gh (8.2 KB)