Hmm, not quite consistent with other unit listings (if you scroll up and down):

https://astropy--11618.org.readthedocs.build/en/11618/units/index.html#module-astropy.units.physical

Ah, was about to post the link! Note that this table is really for the physical types, so it is not supposed to be the same as the other unit listings.

One question is whether it would make more sense to do the mapping by physical type (rather than the unit). Or perhaps have both, though I feel that is a bit superfluous.

Maybe @adrn , @namurphy , or @nstarman can have a look...

One question is whether it would make more sense to do the mapping by physical type (rather than the unit). Or perhaps have both, though I feel that is a bit superfluous.

For xref in #11595 I feel quite strongly that the mapping should be by physical type. I think this also makes a lot more sense physically, where different unit systems have a different base unit corresponding to each physical type. In #11595 I had columns : "physical type" and "example unit" for the above 2 reasons.

But the Latex representation is great! so much better than what was in #11595.

OK, perhaps I should switch it around. It feels like it would be best to sort the physical type then, which is a bit tricky given that some units are associated with multiple types. I guess then maybe we should have 3 columns: phys-type-name, unit, other names in same physical type.

OK, I'll push a change with a new layout. Since I think that will remove the previous one, let me paste how that looked here:

Thank you for doing this! I think this table is going to be really helpful.

One thing that the above screenshot of the table reminded me of... Right now using str on a PhysicalType has the resulting behavior:

>>> print(u.m.physical_type)  # single physical type name
length
>>> print(u.Pa.physical_type)
{'energy density', 'pressure', 'stress'}  # multiple physical type names

Should we change this so that str returns something like this instead?

>>> print(u.Pa.physical_type)
energy density, pressure, stress

The reason why is that if someone uses str on a PhysicalType to make the title for a plot, the set notation is not going to be what they would probably want.

@namurphy. I think that is a good suggestion for __str__ and would also help with @pllim's comment. The __repr__ method should be kept as the annotated set, like it is currently (though it might be improved so that eval(repr(x)) == x, as suggested in https://docs.python.org/3.8/library/functions.html#repr)

The __repr__ method should be kept as the annotated set, like it is currently (though it might be improved so that eval(repr(x)) == x, as suggested in https://docs.python.org/3.8/library/functions.html#repr)

I originally had some hesitations about changing __repr__ like that, since...

• Users should not be instantiating PhysicalType directly but rather using get_physical_type or the physical_type attribute of units, and
• Instantating PhysicalType requires putting in the corresponding unit, and there's potential ambiguity about what unit to actually put in there (e.g., Pa vs. whatever Pa is in SI base units).

I suppose the first thing isn't really that big of a factor, and the second could be resolved by either using the SI decomposition, or whatever units were used when originally instantiating each PhysicalType. My preference would be using the SI decomposition since that's closer to what's used in lists of physical types. Some possibilities would then be:

PhysicalType(m, 'length')
PhysicalType(Unit('m'), 'length')
PhysicalType(m * s, {'absement', 'sustained displacement'})
PhysicalType(Unit('m s'), {'absement', 'sustained displacement'})

Changing __repr__ would be scope creep for this PR so maybe a different PR would be best.

I originally had some hesitations about changing __repr__ like that, since...

• Users should not be instantiating PhysicalType directly but rather using get_physical_type or the physical_type attribute of units, and
• Instantating PhysicalType requires putting in the corresponding unit, and there's potential ambiguity about what unit to actually put in there (e.g., Pa vs. whatever Pa is in SI base units).

I suppose the first thing isn't really that big of a factor, and the second could be resolved by either using the SI decomposition, or whatever units were used when originally instantiating each PhysicalType. My preference would be using the SI decomposition since that's closer to what's used in lists of physical types. Some possibilities would then be:

It's definitely not an urgent need. Many objects in astropy were chosen to not have round-tripable reps. But it's always nice when it can be done and is a small change. I like and also prefer the idea of decomposing to SI.
I didn't realize that PhysicalType was not meant to be directly instantiated after of the initial constructions. Before v4.3 is locked in, should it be made "private" — _PhysicalType, or is keeping it public a good reason to tackle __rep__?

Changing __repr__ would be scope creep for this PR so maybe a different PR would be best.

Agreed.

Note that in the current version of this PR, I do not use __str__ any more, so perhaps we should discuss separately?

But FWIW, I can see the case for changing str - though perhaps with / as separator since we accept that on input too. I do think if we show the unit for __repr__ it should be the one given by the user - e.g., for the various fluxes a simple SI decomposition is considerably less clear.

Note that in the current version of this PR, I do not use __str__ any more, so perhaps we should discuss separately?

Oh, good point, I didn't notice that. Yes, let's continue this conversation in #11625.

Wondering what to do with the PR: are people happy with how the docs look now? - https://astropy--11618.org.readthedocs.build/en/11618/units/index.html#module-astropy.units.physical

My own sense would be to get this in and change it later as the need arises.

@adrn - already reviewed by @nstarman but needs formal approval... could you do the honours?

This PR looks great to me too. Thank you again for doing this!