Clear pint

[hgrecco]

During January I was playing with a few ideas for next Pint version (which will come in April 2025)

As per NEP29, it will support Python 3.11+ and NumPy 1.23+. I would like to have:

Py3.11: Drop support for Python 3.10.

Better packaging/tooling/etc: For this I propose moving to pixi/uv/ruff as we did with https://github.com/maurosilber/poincare It works like a charm, makes testing easier and ci faster.

TOML: Move the definition file from the custom format to TOML (I was really happy to see #2127 🎉 )

Composition: The delegates and facets refactoring was the first step in this direction. I think we can do the same thing with some other parts making Pint easier to understand and test. And flattening the Hierarchy.

Generics: Something that I tried is to rework how generics are used within Pint. The thing that worked best is to have a single generic for the non_int_type, that is used both in the magnitude and unit exponent. Not sure if this is the best idea.

Any other suggestions?

[andrewgsavage]

Adding typing for the unit to quantity looks like it would be a big improvement. Astropy have got it working! There's an array-api implementation, which I am not quite sure where it may be helpful! It allows some scipy functions that don't use or return scalars to work. May be helpful for dask or cupy.

…

On Fri, 14 Feb 2025, 02:50 Hernan Grecco, ***@***.***> wrote: During January I was playing with a few ideas for next Pint version (which will come in April 2025) As per NEP29, it will support Python 3.11+ and NumPy 1.23+. I would like to have: *Py3.11*: Drop support for Python 3.10. *Better packaging/tooling/etc*: For this I propose moving to pixi/uv/ruff as we did with https://github.com/maurosilber/poincare It works like a charm, makes testing easier and ci faster. *TOML*: Move the definition file from the custom format to TOML (I was really happy to see #2127 <#2127> 🎉 ) *Composition*: The delegates and facets refactoring was the first step in this direction. I think we can do the same thing with some other parts making Pint easier to understand and test. And flattening the Hierarchy. *Generics*: Something that I tried is to rework how generics are used within Pint. The thing that worked best is to have a single generic for the non_int_type, that is used both in the magnitude and unit exponent. Not sure if this is the best idea. Any other suggestions? — Reply to this email directly, view it on GitHub <#2131>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADEMLEBKG3R4VEK5JTEEVXL2PVKXNAVCNFSM6AAAAABXDUG2CCVHI2DSMVQWIX3LMV43ERDJONRXK43TNFXW4OZXHE3DGNJXGE> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[hgrecco]

I have make a "large" PR in #2132
ping @andrewgsavage @jules-ch

While I use pixi (https://pixi.sh) because is awesome, the pip or uv workflow to install, test and use should work fine.

I would like to merge it ASAP to master to avoid breaking other future PRs.

[jules-ch]

I did a working example of a toml branch back in the day here:

https://github.com/jules-ch/pint/blob/unit_toml_definitions/pint/unit.toml

Need to get back to it at some point haha. I'll look into the PR

[jules-ch]

Astropy is using this https://github.com/astropy/astropy/blob/b817ec3f90463b4dba3ae94372792445fd4cc235/astropy/units/quantity.py#L337 to create annotated types, seems like a good idea taht we can borrow from them. That's what you're talking about @andrewgsavage ?

[andrewgsavage]

yea

there's a lot of unit related typing discussion in https://github.com/quantity-dev/quantity-api/pull/1/files

[jules-ch]

I feel like the facets as Mixins is adding quite a lot of complexity sometimes, especially when trying to typing stuff.
About composition, delegates are quite usefullike formatter that was initiated by @keewis.
I didn't have much time last year, I'll try to get back to simplifying bits of the code base, I feel it's quite complex sometimes and could use some simplification.

[hgrecco]

I feel like the facets as Mixins is adding quite a lot of complexity sometimes, especially when trying to typing stuff.
I agree, the idea is to flatten the Quantity/Unit/Registry class

[hgrecco]

Everything seems to be working now. If I see no showstoppers, I will merge to master in a few hours and then start merging some minor commits that I already have to improve some tests and some typing issues before a large refactoring.

[hgrecco]

done!

[hgrecco]

done!

[hgrecco]

Just created a PR #2135 to fix small annoyances over many tests and be more stringent regarding some warnings/xfail.

[hgrecco]

done

[hgrecco]

Just created a PR #2136 to improve the code quality of pint-convert

[hgrecco]

done!

[hgrecco]

After #2135 and #2136 are merged:

• A large PR improving small things about import, typing and similar things. No real change, just preparing the field.
• A PR removing deprecated stuff

[hgrecco]

Proposal for generics: something that is quite unique about Python is that we allow users to choose the non_int_type, which default to float but I have seen multiple applications using Decimal, Fraction and even some custom types. This is great for many use cases that want to avoid certain rounding errors. There are two places where this impacts: magnitude (Quantity) and exponent (Unit) values.

Questions:

1. Should we make it generic for the magnitude non_int_type?
2. Should we make it generic for the exponent non_int_type?
3. If both are true, should they be constrained to have the same non_int_type?

[andrewgsavage]

although maybe a seperate exp type is not needed with #2108

[jules-ch]

About the exponent, I want to experiment shifting to int or fraction for everything. Float with units just doesn't make sense. Didn't saw this PR I'll take a look. Genericity for exponent does not make sense IMO.

[hgrecco]

The main problem is (1) performance and (2) interoperability of numerical type.
(1) You could argue that floats do not make sense in general and people should always use decimal (this is actually what Cobra, a python like language, does). How many times we have seen this a question related to this in the Pint issue tracker? But it puts a penalty on calculation speed, so that is why give users the choice
(2) If you select a non float type for your exponent and magnitude, you have to teach users to use this types in their code and/or provide infrastructure to automatically acomodate for it.

[jules-ch]

When can still convert float to Fraction for Unit and not sure about the penalty for computation.
When using Decimal for Magnitude sure.

Using Fraction will ease reduction and prevent bugs for quantity that just doesn't make sense physically. The only time I found those were weird regression where units just doesn't make sense and we could just add units at the end of those equations.
Anyway that's another discussion to have but I'm inclined to not support multiple types in the Unit exponent for simplicity and correctness.

[hgrecco]

Lets continue the discussion on #1770