Make broadcast settings visible on users of with_container_arithmetic

[inducer]

This is to support use cases like illinois-ceesd/mirgecom#331, where the information that with_container_arithmetic has about the desired broadcast behavior of a type would also be useful to have. To make it available, this just shoves it into some (undocumented, for now) class attributes. In the linked use case, this would help (e.g.) avoid the need for hardcoding DOFArray. Instead, it could check whether np.ndarray is in type(obj)._outer_bcast_names and then follow that behavior.

I also have a distinct feeling that this might also be a bad idea. @alexfikl, got a gut feeling on this one?

cc @majosm

[alexfikl]

Is it worth moving the outer function somewhere in arraycontext.container? That way it would keep all of this a bit more contained if we ever decide to change it.

Besides that, no particular feeling of impending doom on my side 🤷

[inducer]

Is it worth moving the outer function somewhere in arraycontext.container?

I'd be all for that, especially since it'd help avoid use of private attributes across package boundaries. @majosm? (Added you to the repo just in case.)

[inducer]

Thanks for taking a look!

[majosm]

Is it worth moving the outer function somewhere in arraycontext.container?

I'd be all for that, especially since it'd help avoid use of private attributes across package boundaries. @majosm? (Added you to the repo just in case.)

Just wondering: how come the specifications in with_container_arithmetic don’t become public? Would it be useful for external code to have access to that so it can build on top of the existing mapping functionality?

[inducer]

Just wondering: how come the specifications in with_container_arithmetic don’t become public? Would it be useful for external code to have access to that so it can build on top of the existing mapping functionality?

I could very well see it being useful. I just have commitment anxiety about the interface... it seems kind of janky and poorly defined.

[majosm]

@inducer Where should I stick outer?

[inducer]

container.traversal, and importable from the root?

[majosm]

#46

[inducer]

Closing in favor of #46.