Make PhysicalType instances support string methods with deprecation warnings

@mhvk

Description

Prior to #11204, the physical_type attribute of units was a string with the name of the unit. #11204 transformed the physical_type attribute into instances of the new PhysicalType class. #11204 did preserve much of the behavior of the string API (such as having == work between PhysicalType instances and strings), but there were a few ways that it did not. A few of these ways are being discussed in #11204 starting with this comment. A lot of this could probably be done with this suggestion from @mhvk.

Suggestions on specific string behaviors to include and test for would be appreciated!

I might be able to address this on tomorrow or Friday if I don't have too many side effects from my vaccination later today, but anyone else should feel free to address this in the meantime.

Will this be fixed by #11625 ?

Will this be fixed by #11625 ?

Thank you for the reminder! I completely forgot I raised this issue. Yep, #11625 will fix this.

== works, but in does not. This used to result in True in astropy 4.2:

>>> from astropy import units
>>> myunit = units.ph / units.m / units.m / units.s / units.um
>>> 'flux density' in myunit.physical_type
True

But results in False in astropy 4.3.post1:

>>> myunit = units.ph / units.m / units.m / units.s / units.um
>>> myunit.physical_type
PhysicalType('photon flux density wav')
>>> 'flux density' in myunit.physical_type
False

This works though (and this is how I solved it in our codebase):

>>> 'flux density' in str(myunit.physical_type)
True

And using the full string works with in:

>>> 'photon flux density wav' in myunit.physical_type
True

I'm not sure this warrants a separate issue. Support for == is probably good enough for most cases.

Oh sorry, it seems to be fixed already but not yet in a release?

Ah, now I understand, in now works like this:

>>> units.Pa.physical_type
PhysicalType({'energy density', 'pressure', 'stress'})
>>> 'pressure' in units.Pa.physical_type
True

So it doesn't make any real sense to support my intended usage in this new scheme. Oh well, that's fine with me. So don't change anything! 😃

Glad that you figured it out!

I seem to have caused a lot more trouble with #11204 than I had intended! 😅

The trouble is worth it though. Units and physical types are extremely hard to get right and the astropy approach of taking it one step at a time is great. And every change will break someone's workflow.

We use the physical type to determine whether a value is an integrated flux or a flux density, #11204 seems to be a step in the right direction to do this properly through dimensional analysis. So thank you!

Navigation Menu

Repository navigation

Make PhysicalType instances support string methods with deprecation warnings #11617

Description

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Make PhysicalType instances support string methods with deprecation warnings #11617

Description

Description

Activity

namurphy commented on Apr 21, 2021

pllim commented on Apr 28, 2021

namurphy commented on Apr 28, 2021

hugobuddel commented on Jul 30, 2021

hugobuddel commented on Jul 30, 2021

hugobuddel commented on Jul 30, 2021

namurphy commented on Jul 30, 2021

hugobuddel commented on Jul 31, 2021

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions