Plans for 0.24

[hgrecco]

I would like to share some thoughts about the Pint 0.24

Release date, Python and Numpy Support

According to NEP29, in Apr 05, 2024 Minimum Python and Numpy versions will be 3.10+ and 1.23+. I think we should aim for after this date (Apr/May).

Delegates

One of my biggest concerns is how Pint is growing, resulting in numerous interconnected parts. This might turn into something hard to understand, test and maintain. In the last releases, I have been working to preemtively fix this in a backwards compatible manner. The facet rewrite was one of these projects, and some additions like parse_units_as_container were also done in the same spirit. Now is time to move forward with other parts.

Formatter Delegate: string formatting is becoming more and more complex as users request different (reasonable) means to represent quantities (both magnitude and units). Right now, formatting is intertwined with the registry. Adding more configuration settings increases the registry API surface and makes it harder to maintain and upgrade. The plan is to create a Formatter Delegate. All formatting settings will work directly on the delegate (for a yet unspecified number of versions, we will map this to existing registry functions for backward compatibility.). Also, users will be able to build their own formatter and replace the existing one. See stub here.

Is there any other part that you think is worth making a delegate?

Code simplification

The LazyRegistry was built to avoid adding a time-consuming operation on Pint import. While the code is small, it is an ugly hack. The cache (introduced a couple of versions ago) provides a way to load/save the internal registry dictionaries in a fast and effective manner. The plan is to remove the LazyRegistry and replace it with a cached registry.

What do you think?

Performance

I have also been improving the performance lately. Some common operations are 66% faster. But I think there is still room for improvement, without loosing Pint features (it is easy to make a faster unit converter package, the hard part is to do it feature rich as Pint). The question is which operations should be optimized and how to do it. Conversion is one of such things, and this could be improved. One way to speed up conversion is to bypass certain layers. For example, instead of calling Registry.convert that will go through the whole hierarchy checking if the units are multiplicative or non-multiplicative, go directly to the appropriate method. This could be achieved by storing the correct method when building/parsing the unit. Or at least keeping track if the unit is multiplicative/non-multiplicative to then do a quick dispatch.

Any other ideas?

Contexts

Contexts are one of my favorite Pint features, but they are really hard to optimize and, more importantly, adds a burden to everything else that could be optimized. The main reason is that conversion rules and units change within a context, that can be enabled and disabled at will. This requires an extra cache layer. Without changing the API a lot, what can we do to make the code simpler?

[hgrecco]

The Formatter delegate is looking good. Join the conversation in #1913