(One) namespace?

[lucascolley]

An idea that we seem to be converging on is that we don't just want to standardise the Quantity, Unit, and Dimension classes—rather, we would also like to standardise some sort of QuantityNamespace which could contain things like:

• asquantity to construct a Quantity
• asunit to construct a Unit
• asdimension to construct a Dimension

The primary motivation for this so far seems to be that we can circumvent constraining class instantiation by using constructor functions instead. But there is the more general point that favouring namespace functions over object methods (like the array API standard has done) makes adoption easier.

---

My primary question here: does it seem like we could have just one namespace for all of these things?

• Would existing libraries be comfortable with adopting that?
• Are we missing out on anything by imposing this restriction that these functions must come in a shared namespace?

ping @nstarman @mhvk @neutrinoceros @andrewgsavage @SimonHeybrock

[mhvk]

I'm not sure about Quantity -- in principle, any Quantity could work with any conformant unit which has a way to compare and convert plain arrays, and thus Quantity itself would really only need to provide an __array_namespace__. So, I think Quantity should be able to get anything it needs via q.unit.__unit_namespace__() (or whatever we call it).

Conceptually, I think units and dimensions are more closely tied together, so those sharing a namespace would seem to make sense. Though I guess in principle here too one could go via unit.dimension.__dimension_namespace__() -- it is just quite a bit less obvious it is ever going to be useful to tie the unit provided by one package to the dimension provided by another.

...

Actually, thinking a bit more, what I stated above simply implies that Quantity does not really have a need, but of course, the converse is not true: given a unit, one surely wants to be able to create a Quantity, so it does seem logical that the unit namespace contains asquantity.

Though probably it is good if Quantity.__array_namespace__() also provides the option to initialize the same Quantity, perhaps simply via .asarray (with an extra unit argument).

[neutrinoceros]

quantity classes treating the API Protocol as an ABC

For what it's worth I think we should be very careful about supporting this (and avoid doing so, unless it becomes a necessity): I think Protocol-based class hierarchies are a wonderful way to avoid, or get rid of inheritance, and I'm worried that even suggesting using a protocol as a base class undermines their primary purpose: moving away from nominal subtyping and the uncontrolable amounts of coupling it creates.

[nstarman]

@neutrinoceros. Oh I fully agree about the dangers of inheritance. But we literally cannot stop someone from inheriting from a Protocol as an ABC. The only question is whether def __unit_namespace__(self) -> UnitNamespace: is treated as an abc.abstractmethod or not.
*note: I've started advocating for __metrology_namespace__ as this covers dimensions, units, and quantities.

[nstarman]

In your example MyQuantity uses AstropyUnit. Are there any cases where a custom unit class inheriting from AstropyUnit would be needed? I can't think of any examples for pint.

@andrewgsavage I guess so... some kind of function-unit? or if you wanted to use Astropy units but also needed them to be lazily resolved then a custom CompositeUnit would be needed. Or if you wanted to have classes with jax PyTree methods defined (https://docs.jax.dev/en/latest/_autosummary/jax.tree_util.register_pytree_node_class.html#jax.tree_util.register_pytree_node_class). It's a wild world 😆.

[neutrinoceros]

But we literally cannot stop someone from inheriting from a Protocol as an ABC

sure, but it's still very different to say "We cannot stop you from shooting your own foot." or "Here's your gun. Need ammo ?".
I think the gain from not providing (importable) implementations at all (no 2-ways coupling) outweights any convenience for implementers.

[nstarman]

Putting an example implementation in the docstring is also good 👍.

[lucascolley]

EDIT: moved to thread https://github.com/orgs/quantity-dev/discussions/7#discussioncomment-12217973

[nstarman]

Cross-posting: What about __metrology_namespace__ for a unified name across dimensions, units, and quantities? metrology is the name of the field of study of all these things.

[neutrinoceros]

strong +1 on this