Think about switching to `@cached_property`-style caching

[kalekundert]

The library would be much simpler conceptually if it were to just calculate a value the first time it was accessed, then overwrite itself with that value. AppCLI attributes just be elaborate default values: nothing more and nothing less.

The simplicity of this mental model really appeals to me, but I'd have to modify/eliminate some existing features:

• Loading: This basically indicates that the config list has changed, and that attributes may be out of date. Right now I just increment a cache_version variable every time the configs change, and the attributes check that value every time they're accessed. In other words, the logic happens at access-time. To avoid this, I'd have to move this logic to load-time. That means I'd either keep track of every attribute that's been assigned to, or search the instance for overwritten attributes.
  • The real trick here is that some configs may depend on previous values, e.g. DocoptConfig can use values from before it's been loaded as default values. In order to support this, I'd need to have an "update in progress" mode that would cache values in pretty much the same way as the current code, although after the load is complete it could resolve things.
• Get/set callbacks. Although I could return a caching descriptor similar to what I currently do when I get these arguments. I could also add a frozen/read_only argument to force the use of a descriptor without a get/set callback. The dynamic argument discussed in #18 would also prevent overwriting.
  • Note that the get callback is used extensively by stepwise_mol_bio to apply the bind() function. So if I want to get rid of this feature, I'll have to think about how I'd handle those use cases.
• Am I forgetting any other features that would be impacted?

Overall, this seems like it'd actually be a pretty small change. It wouldn't simplify the code at all (even though I still think of it as a conceptual simplification), because I'd have to keep all the current code to support these more complex cases. But I also wouldn't need to rewrite much existing code. Here's some pseudo-code:

• On attribute access:
  • If update_in_progress == True: Same as below, but cache instead of writing to instance dict.
  • If update_in_progress == False: If have cached value, and the cache isn't stale, use it. Otherwise, recalculate. If get/set/frozen specified, write value to cache. If dynamic specified, don't write to cache. Otherwise, write value to instance dict and clear cache.
• On load:
  • For each appcli attribute:
  • Clear instance dict cache.

[kalekundert]

I ran into a problem implementing this: python doesn't let the instance dictionary shadow the descriptor if the descriptor implements __set__ or __del__. So I'd need to get rid of those methods in order for this feature to be worth it. Can I do that?

• I'd have to get rid of the ignore option, but that was always a bit of a kludge.
• I won't be able to directly set the metadata for assignments. I can sorta figure it out by inspecting __dict__ in get_meta(), but that requires holding onto the cached value for all of time.
• get won't be applied to values set by assignment, which means that get basically won't work. The only way to deal with this is to use a different parameter class when the get argument is specified. Some metaclass magic is necessary to hide this complexity from the user and any subclasses, but I did it, and it didn't turn out to be that bad.

The metadata issue is the hangup. Even though it's a small feature, it's something that's squarely within appcli's purview, and there's just no way to get it right without __set__.

I saved my work-in-progress to the feat-fast-cache branch, but I'm going to abandon this feature for now.