Three Dollar Quill

Quick name thought: some CI products call it a "matrix", but... On the one hand, I want to say "tensor" because more dimensions, but apparently a tensor is more identified with a generalization of a linear transformation, and linear transformations can be represented by matrices, but the grids the CI products generate don't have anything to do with linear transformations.

What we have is some kind of generalized Cartesian product and the ability to map over the result. I mean, except that the Cartesian-product-like-thing is idempotent, and commutative, and associative. So, like, at that point, what is it? (I guess if an ordering is defined over the labels, then we can fold the Cartesian product over an ordered set of labels mapped to typed sets?)

Anyway, I want to change gears, so I'm going to prototype some code that I won't be able to use for a while.

...

Okay, done for now, got a few things to think about while I wait to be able to use this. Basically, I wanted a wrapper around contextvars, using contextlib, so I can have context managers controlling the values of box and selection instead of passing them through every function, mostly unchanged. This is pretty easy to throw together, but I did add just enough functionality to raise questions. Like, the basic functionality is to have a get() helper method, and a set() method that returns a context manager. But I anticipate that I'll want to express the logic a lot of the time as "update whatever value there is, with this function" rather than "temporarily replace the current value with one that happens to be related to it". So I wrote an update() context manager, and it's like, if there isn't a value in the variable currently, do I want that to fail outright, for the caller to specify a default value to get(), or for the caller to provide a default value that replaces the act of calling the function passed in?

I guess I'll need to figure out what I want to happen in my actual use cases for this stuff. I think I'd want the get() to fail, and a helper function in the stack to catch the LookupError and convert it to something MOTR-specific? Which is certainly easy to implement from the standpoint of the code I'm looking at now...

Anyway, I'm tired and foggy. Time to wind down.

Good night.