Blob interface can be simpler and consistent between inherited classes

[CiottiGiorgio]

class StateBlob(ABC):
    def __init__(self, num_keys: int):
        self.num_keys = num_keys

while

class AccountStateBlob(StateBlob):
    def __init__(self, keys: Optional[int | list[int]] = None):

and

class ApplicationStateBlob(StateBlob):
    def __init__(self, keys: Optional[int | list[int]] = None):

makes it hard to use StateBlob in an abstract way and then substitute with whatever implementation (signature on the abstract should match signatures on the concrete).

Furthermore, I think

class Blob(ABC):
    def __init__(self, key_limit: int, /, *, keys: Optional[int | list[int]] = None):

could be much simpler. Maybe always accepting just a int | Tuple[int, int] is enough? I'm thinking of the case where a single global/local space could be storing multiple blobs so it makes sense to either specify the size or a range of slots.

[barnjamin]

I thing in the proposed constructor, the key_limit and the keys passed an int could end up conflicting since they represent the same setting?

I'm thinking of the case where a single global/local space could be storing multiple blobs

can you say more about this?

[CiottiGiorgio]

I thing in the proposed constructor, the key_limit and the keys passed an int could end up conflicting since they represent the same setting?

I agree, to me the keys with the proposed signature should be enough for all use cases?

can you say more about this?

I'm writing data structures like lists, vectors and maps using Beaker Blob as a parent class and so the user should make sure on its own that the slots used to represent the DS(s) do not overlap. In my plan, a global state should hold at the very least a list and a couple of maps. This possibly plays out with the same algorithm used in PyTeal for allocating ScratchSlot to ScratchVar in such a way that they don't overlap. It could also play out with ReservedState but in the interest of keeping things simple, explicit slot numbers can be provided.