Replies: 2 comments 1 reply
-
|
you can make a custom unit file that has memory as a base unit. I think redefining base units doesn't work and needs fixing. yes, accessing the prefix for a unit feels like something that is missing from pint and would be a welcome addition . I'm not sure what such a function would return,. A PR is welcomed! |
Beta Was this translation helpful? Give feedback.
-
|
there is this code in the latex formatter that can be moved into the Unit class |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi all, I'm new here so forgive me if this has been discussed. I've just started evaluating Pint to replace the half-hearted "units" API in one of my applications. I say "units" in quotes because each unit is really just a constant scale factor so that expressions like:
look like quantities with units, but evaluate to a plain integer.
This is fine everywhere except formatting and parsing. Formatting is naive and amounts to a lot of
match/casebranches to format things correctly, while parsing is broken if the units in your quantity string are not one of the supported constants or if the case doesn't match likegbinstead ofGB.The only upside of doing something bespoke is that I have fine-grained control over formatting, which is nice since this application interacts with the Kubernetes API where quantity strings are... strange. Kubernetes only really accepts unitless quantity strings like
1Gi(1 Gibibyte),1073741824(also 1 Gibibyte),192m(192 milliCPU), or 1 (1 CPU or 1000milliCPU). Notice also the lack of any spaces between the magnitude and units portions of the strings - this is also strictly enforced by the Kubernetes API's quantity parser which uses the regular expression:'^([+-]?[0-9.]+)([eEinumkKMGTP]*[-+]?[0-9]*)$'So far I've attempted my own extensions to
pintto cover Kubernetes-specific uses looking something like this:which as you can see contains a few hacks that rely on internal API, and sadly doesn't quite work. While it does work for quantities like:
since
CPUis defined to be a root unit, it fails for memory quantities:since the root unit for
GiBis actuallybitsnotbytesmaking theremovesuffixcall a no-op. I tried also usingto_reduced_unitsinstead, but this has the same issue with memory quantities because e.g.,256 * u.GiBreduces to a dimensionless quantity which again makes theremovesuffixcall a no-op.The idea I wanted to discuss here is making the
Unittype "prefix-aware" such that given an object of typeUnitI can getUnit.prefix(es)andUnit.baseseparately. Any prefixes would represent the scale factors for quantities and measurements, while the base units would represent, well... the base units. In this way prefixes could be thought of as modifying the base units they're attached to instead of the combination of prefix and base units being thought of as a single distinct unit which I think is the paradigm currently.For something like
mCPUthis would resolve tom(milli) for the prefix andCPUfor the base unit; for memory something likeGiBwould resolve toGiandBfor the prefix and base units respectively; and so on.If necessary to disambiguate prefixes that might collide with a base unit like
mformilliandmformetersorcforcentiandcfor the speed of light a prefix string could be represented with the trailing-like indefault_en.txte.g.,m-formilli. A convenience method could easily be provided to strip the trailing-for clients during formatting if needed.With prefix-aware units one could easily separate base units and their prefixes for formatting purposes like:
Looking forward to everyone's thoughts!
Beta Was this translation helpful? Give feedback.
All reactions