SciPy Constants in Python

One of the most useful submodules for physics and engineering is scipy.constants. Rather than a set of solvers or algorithms, it's a library of data: the exact, internationally recommended values for hundreds of scientific constants, from the speed of light to Avogadro's number, all ready to import instead of retyped from memory or copy-pasted from a search result.

Every value in the module tracks CODATA (the Committee on Data for Science and Technology), the body that periodically publishes the internationally agreed-upon values for fundamental physical constants. That matters because a hardcoded '3.14159' or a hand-typed '299792458' is both a precision risk and a transcription risk — a single mistyped digit silently corrupts every downstream calculation, and scipy.constants exists specifically to remove that failure mode.

Getting access to it is a single import: from scipy import constants or import scipy.constants as const. From there, constants behaves like a namespace of read-only data — no solving, no fitting, just accurate numbers other SciPy submodules (optimize, integrate) and your own physics or engineering code can build on.

The primary purpose of scipy.constants is to give scientific and engineering code a single, trustworthy source of truth for values that should never vary between scripts, teams, or codebases. Two different files hardcoding slightly different approximations of Planck's constant is a subtle but real source of bugs in physics simulations, and it's entirely avoidable.

Beyond correctness, there's a readability argument: constants.c tells a reader exactly what quantity is being used, while 299792458 demands they either already know what that number is or go look it up. The name documents intent in a way a bare literal never can, which matters enormously when a research script gets handed off or revisited months later.

This is also why scipy.constants is worth learning even outside heavy numerical work — anywhere a script touches physics, chemistry, or precise unit conversion, reaching for the library instead of a remembered approximation is the difference between a reproducible result and a silently-off one.

scipy.constants mixes two different kinds of values under one namespace. Mathematical constants like const.pi and const.golden (the golden ratio) are defined values with no measurement uncertainty — pi is pi, to as many digits as floating point allows. Physical constants like const.c, the speed of light in a vacuum, describe something about the physical universe.

The speed of light is a particularly clean example: since the 2019 redefinition of the SI base units, const.c is exact by definition (299,792,458 m/s exactly), not a measured approximation with error bars. Other physical constants — the gravitational constant, the electron mass — are experimentally measured and do carry a small uncertainty, which is why scipy.constants also exposes uncertainty values for the ones that have them.

Both kinds of constants are accessed the same way, as a plain attribute on the module: const.pi, const.c, const.h (Planck's constant), const.G (gravitational constant). No function calls, no unit arguments — just a name that resolves to a float.

The exact speed of light in a vacuum lives at const.c (with const.speed_of_light also available as a more descriptive alias for the same value) — one of roughly two dozen especially common constants SciPy promotes to a direct, short module attribute for convenience: pi, c, h, hbar, G, e, m_e, m_p, N_A, k, R, and a handful more.

That short list is deliberately small; it covers the constants used often enough to deserve a quick name. For anything more specialized — the mass of a muon, the Bohr radius, the Rydberg constant — scipy.constants exposes a much larger dictionary called physical_constants, keyed by descriptive string names rather than short attributes.

Each entry in physical_constants is a tuple of (value, unit, uncertainty), not just a bare number, so const.physical_constants['electron mass'] returns the value in kilograms, the unit string, and the measurement uncertainty together — useful when precision and traceability matter, not just the raw magnitude.

Beyond fundamental physical constants, scipy.constants ships a large set of unit-conversion multipliers: SI metric prefixes like const.kilo (1e3), const.mega (1e6), const.milli (1e-3), and const.micro (1e-6), plus time conversions like const.minute (60), const.hour (3600), and const.day (86400) — all expressed in terms of seconds, the SI base unit.

The library goes further still, covering imperial-to-metric conversions (const.mile, const.inch, const.pound), energy units (const.calorie, const.eV for electron-volts), and pressure units (const.atm, const.bar), among others. Every one of these is just a plain float multiplier, not a conversion function — there's no convert(value, from_unit, to_unit) call.

That design keeps the API uniform: whether you're converting kilometers to meters or calories to joules, the pattern is always 'multiply or divide by the right named constant,' which is simple to read and simple to get wrong if you don't think carefully about which direction the conversion goes.

constants.kilo returns exactly 1000.0 — the SI metric prefix meaning 'one thousand times the base unit,' expressed as a Python float. It's easy to assume that at first glance, but it's worth being precise about it, because the metric meaning of 'kilo' isn't the only meaning of that prefix floating around in software.

In computing, 'kilo' is often used loosely to mean 1024 (2^10), as in a 'kilobyte.' scipy.constants keeps these concepts cleanly separate: constants.kilo is the decimal/metric 1000, while the binary prefixes have their own distinct names — constants.kibi (1024), constants.mebi (1024**2), and so on — matching the official IEC binary-prefix naming (kibi, mebi, gibi).

That separation is intentional and worth internalizing early: reaching for constants.kilo when you actually meant a binary size produces numbers that are subtly wrong by a factor that grows with each additional prefix level, and the bug won't throw an error — it will just silently misreport memory or file sizes.

Using a prefix constant to convert units correctly comes down to dimensional analysis, not memorization: to go from a value expressed in a 'kilo-' unit to the base unit, you multiply by constants.kilo, because one kilo-unit is defined as 1000 base units. To go the other direction — base unit to kilo-unit — you divide by the same constant.

This matters because the direction is easy to get backwards under pressure, especially with less familiar prefixes. A useful sanity check: think in terms of 'how many base units are in one of these' — for kilo, the answer is 1000, so multiplying a kilo-quantity by constants.kilo should always make the number bigger (more of the smaller base unit), never smaller.

ADA's upcoming challenge tests exactly this reasoning with a concrete case: converting a weight already expressed in kilograms into grams, which is precisely a 'kilo-unit to base-unit' conversion.

The correct conversion is grams = weight * constants.kilo. Since a kilogram is defined as 1000 grams, multiplying the kilogram value by constants.kilo (1000) produces the equivalent value in grams — exactly the 'kilo-unit to base-unit' direction covered a moment ago.

The two wrong options fail for different reasons. constants.kilo(weight) treats the constant as if it were a conversion function, but every value in scipy.constants is a plain float, not callable — calling it raises a TypeError: 'float' object is not callable. weight / constants.kilo divides instead of multiplies, which would actually convert grams into kilograms — the opposite of what's being asked for, and a number 1,000,000 times too small if applied here.

The underlying lesson generalizes beyond this one example: scipy.constants gives you the correct numeric factor, but it can't catch a conversion applied in the wrong direction — that reasoning is still on you.

With named constants and conversion multipliers in hand, a physics or engineering script no longer depends on anyone remembering (or correctly retyping) a dozen scattered numeric literals. constants.c, constants.h, constants.G, and the metric/time/imperial multipliers all come from the same audited, CODATA-backed source, which is what 'perfectly accurate' really means here — not infinite precision, but freedom from transcription error and stale approximations.

This also pays off in code review: a reader who sees energy = mass * constants.c**2 immediately recognizes the physics being expressed, where the same line written with a bare 299792458**2 requires either prior knowledge or a detour to verify what that number is.

The combination of fundamental constants plus conversion factors is what makes scipy.constants genuinely useful day to day — not just for exotic physics, but for the mundane unit conversions (grams to kilograms, minutes to seconds, miles to meters) that show up constantly in engineering and data pipelines.

scipy.constants rarely does the heavy lifting on its own — its real job is supplying trustworthy numeric building blocks to the rest of a scientific Python pipeline, whether that's a scipy.optimize routine fitting a physical model or a scipy.integrate simulation stepping forward in time. Getting the constants right is a prerequisite for those calculations to mean anything.

Unit-mismatch bugs are a well-documented real-world hazard: NASA's Mars Climate Orbiter was lost in 1999 because one team's software produced thrust values in pound-force-seconds while the receiving system expected newton-seconds, and the mismatch was never caught. scipy.constants doesn't prevent that class of mistake automatically, but consistently converting through named constants instead of hand-typed factors removes an entire category of that risk.

From here, the next lesson in this course moves into scipy.optimize — and having accurate constants ready to plug into an objective function or a physical model is exactly the kind of groundwork this module was building toward.

One of the most useful submodules for physics and engineering is scipy.constants. It contains the exact mathematical values for hundreds of scientific constants.

What is the primary purpose of the scipy.constants submodule?

• →To provide highly accurate, built-in values for scientific constants like the speed of light or Pi.
• →To declare variables in Python that cannot be changed.
• →To test the CPU speed of your computer.

For example, you can get Pi to a high degree of precision, or the exact speed of light in a vacuum, with a single variable call.

Which constant variable gives you the exact speed of light in a vacuum?

• →const.speed
• →const.light
• →const.c

The constants module also provides helpful conversion factors. For example, converting metric prefixes, or changing hours into seconds.

If you print constants.kilo, what value will be returned?

• →1000.0
• →10.0
• →1000000.0

Now, prepare yourself. We are about to enter the ADA Defense Protocol. Ensure you understand how these conversion factors are used mathematically.

ADA DEFENSE: If you have a variable weight = 50 representing kilograms, and you want to convert it to grams, how would you use the constant?

• →grams = weight * constants.kilo
• →grams = constants.kilo(weight)
• →grams = weight / constants.kilo

Threat neutralized. Conversions validated. Your physics calculations will now be perfectly accurate.

Threat neutralized. Concept validated. Proceed to the next section.

Convert Real Units with scipy.constants. Finish seconds_in_minutes(): use the built-in minute conversion factor instead of hardcoding 60.