What should the base classes be?

[thorwhalen]

At some point, I had all KV functionalities separate: had a Reader, Writer, Deleter, Indexer. Code quickly became messy and mro-complex.

So instead I favored having a single KV base (now called “Persister”, which is just MutableMapping with a free __len__ and with clear disabled). The intent was: if the user wants a read-only, they just need to disable the write methods, by subclassing write/delete methods with a “Nope can’t do that” raised.

But that’s also not so clean: The methods exist in the interface, for example. Perhaps better remove them (and all consequential methods — if possible, through static analysis?).

It seems like in the case of KV stores, it would make sense to have a Reader and Persister (subclass of Reader that adds write/delete functionality). That would imitate the Mapping->MutableMapping structure of collections. But what about when we want to add list-like operations like append() and extend()? Should these be separate (a con of a KV acting like a list-like collection is that __iter__ is over keys in Mapping, but values in Sequence)?

What do we use when the KV structure doesn’t quite fit? Collection for sure (__contains__, __iter__ and __len__ — though note that __len__ and contains can both be inferred from __iter__). But when we step up to Sequence (because we want __getitem__) or MutableSequence (because we want __setitem__, or more often, just the append and/or extend), we get stuff we don’t care about (like reverse) or obliges us to define things we don’t need (such as insert). Similarly with with Set and MutableSet: Makes sense if we don’t care about order, but then we get a bunch of other methods we might not want the user to use (such as __gt__, __lt__, __eq__, etc.) because they might trigger large computations.

Is it better to

• get it all, and disable as needed, or
• (the other extreme) forget collections.abc, and just add the methods we need, and have mixins that can be used to infer other methods?