Pint: makes units easy¶
Pint is a Python package to define, operate and manipulate physical quantities: the product of a numerical value and a unit of measurement. It allows arithmetic operations between them and conversions from and to different units.
It is distributed with a comprehensive list of physical units, prefixes and constants. Due to its modular design, you can extend (or even rewrite!) the complete list without changing the source code. It supports a lot of numpy mathematical operations without monkey patching or wrapping numpy.
It has a complete test coverage. It runs in Python 2.6+ and 3.2+ with no other dependency. It is licensed under BSD.
It is extremely easy and natural to use:
>>> import pint >>> ureg = pint.UnitRegistry() >>> 3 * ureg.meter + 4 * ureg.cm <Quantity(3.04, 'meter')>
and you can make good use of numpy if you want:
>>> import numpy as np >>> [3, 4] * ureg.meter + [4, 3] * ureg.cm <Quantity([ 3.04 4.03], 'meter')> >>> np.sum(_) <Quantity(7.07, 'meter')>
To install Pint, simply:
$ pip install pint
and then simply enjoy it!
Although there are already a few very good Python packages to handle physical quantities, no one was really fitting my needs. Like most developers, I programmed Pint to scratch my own itches.
Unit parsing: prefixed and pluralized forms of units are recognized without explicitly defining them. In other words: as the prefix kilo and the unit meter are defined, Pint understands kilometers. This results in a much shorter and maintainable unit definition list as compared to other packages.
Standalone unit definitions: units definitions are loaded from a text file which is simple and easy to edit. Adding and changing units and their definitions does not involve changing the code.
Advanced string formatting: a quantity can be formatted into string using PEP 3101 syntax. Extended conversion flags are given to provide symbolic, LaTeX and pretty formatting.
Free to choose the numerical type: You can use any numerical type (fraction, float, decimal, numpy.ndarray, etc). NumPy is not required but supported.
NumPy integration: When you choose to use a NumPy ndarray, its methods and ufuncs are supported including automatic conversion of units. For example numpy.arccos(q) will require a dimensionless q and the units of the output quantity will be radian.
Uncertainties integration: transparently handles calculations with quantities with uncertainties (like 3.14±0.01) meter via the uncertainties package.
Handle temperature: conversion between units with different reference points, like positions on a map or absolute temperature scales.
Small codebase: easy to maintain codebase with a flat hierarchy.
Dependency free: it depends only on Python and its standard library.
Python 2 and 3: a single codebase that runs unchanged in Python 2.7+ and Python 3.0+.
One last thing¶
The MCO MIB has determined that the root cause for the loss of the MCO spacecraft was the failure to use metric units in the coding of a ground software file, “Small Forces,” used in trajectory models. Specifically, thruster performance data in English units instead of metric units was used in the software application code titled SM_FORCES (small forces). The output from the SM_FORCES application code as required by a MSOP Project Software Interface Specification (SIS) was to be in metric units of Newtonseconds (N-s). Instead, the data was reported in English units of pound-seconds (lbf-s). The Angular Momentum Desaturation (AMD) file contained the output data from the SM_FORCES software. The SIS, which was not followed, defines both the format and units of the AMD file generated by ground-based computers. Subsequent processing of the data from AMD file by the navigation software algorithm therefore, underestimated the effect on the spacecraft trajectory by a factor of 4.45, which is the required conversion factor from force in pounds to Newtons. An erroneous trajectory was computed using this incorrect data.Mars Climate Orbiter Mishap Investigation Phase I Report PDF