_UnitRegistry doesn't know about physical types of composite units

I just found a bug in astropy.units that significantly hampers the functionality added in #3847 …

Apparently, the _UnitRegistry object doesn’t know about physical types of composite units:

>>> from astropy.units import get_current_unit_registry
>>> ureg = get_current_unit_registry()
>>> ureg.get_units_with_physical_type(u.m)
{Unit("ym"),
 Unit("zm"),
 Unit("am"),
 Unit("yearthRad"),
 Unit("yjupiterRad"),
 Unit("ysolRad"),
...etc

But doing the same for, e.g.,:

>>> ureg.get_units_with_physical_type(u.m/u.s)
set()
>>> ureg.get_units_with_physical_type(u.kg/u.m**3)
set()

I think the concept of “physical type” could use an overhaul, but that is a big change and should probably get pushed to v3.0. But for v2.0, we need to find a solution to support these physical type lookups from the unit registry. This might require some hacking of the _UnitRegistry.add_enabled_units() method.

BTW: We didn’t see this in the tests for #3847 because the physical types I used all resolved to irreducible units.

cc @mhvk

[mhvk]

p.s. I don’t really know what to do about the larger question: as you write, it becomes a combinatorial explosion. My own sense is that it is better first to get the systems in place, so that it becomes possible to get a preferred unit for a given physical type. I have never found myself needing a list of possible units…

[mhvk]

closing given the combinatorial explosion mentioned in-line