Add box_namespace to track nested Box names

[JacobHayes]

I'd like to track the "namespace" of nested boxes, which is hard to do in a subclass because of the (necessary) recursive conversions during __init__ and other actions. To handle this, I added a new box_namespace parameter, which is tracked in _box_config, to allow propagating and extending the namespace as we create nested boxes.

Closes #226

[JacobHayes]

FYI: I think newer versions of mypy are a bit more strict about dict.__ior__, so I'll include a quick "fix" for that in this PR (that's why the first commit "failed").

[cdgriffith]

Hey @JacobHayes thanks for the great add!

This is something I have struggled with before #15 so I'm going to do some prodding to see if I can make it unravel in any of the weird ways that bit me before (if I can recall them...), but I'd be very happy if this works solidly!

[JacobHayes]

Sounds great! Feel free to add any new tests and I can take a stab at them if they don't work right away.

[cdgriffith]

I know it's super handy to do this at the start of the function here. But for now will need to keep it in each if block, as this would slow down processes that don't use one of the defaults that require it.

This code wasn't designed for speed from the start, but enough people use it in "semi performant" applications I try to think a little bit about not slowing down some paths they might have optimized for at least 🤷

[cdgriffith]

Same with this needing to be left under the if / elif blocks as above, and will stop repeating myself here, you get the picture ;)

[cdgriffith]

My two thoughts tonight before sleep takes me:

1. (Not required for round 1), look into expanding this to work with BoxList as well.
2. It's great to track this, but I feel if we add it, do we want to "do" something with it. By adding a box_history() or something so it's more accessible. Though at the same time, I feel that if you need this, you're building on top of Box itself somehow so are probably okay working with the config.... hmmm

[JacobHayes]

(Not required for round 1), look into expanding this to work with BoxList as well.

How do you think Boxes inside BoxLists should be named? Eg: should {"a": {"b": [{"c": 5}]}} be something like ("a", "b", 0, "c")?

It's great to track this, but I feel if we add it, do we want to "do" something with it.

Yeah, this is a good point. I'm internally subclassing Box and using this via the config as you say (and then exposing those Boxes to users as an "implementation" detail). I'm ok with using the config, but could see use in a more "public" interface. Were you thinking a box_history function (eg: from box import box_history) or a method on the Box class? I know we need to be careful about name collisions.

(and time for me to go to bed too haha)