TheAlgorithms/Python · error · ValueError
Invalid 'to_type' value: {to_type!r}.\nConversion abbreviati
Error message
Invalid 'to_type' value: {to_type!r}.\nConversion abbreviations are: {', '.join(METRIC_CONVERSION)} What it means
Raised by length_conversion(value, from_type, to_type) in conversions/length_conversion.py:121 when the destination unit fails the same normalization/membership check as from_type. It fires only after from_type already validated, so it pinpoints the second unit: anything not normalizing to mm/cm/m/km/in/ft/yd/mi — e.g. 'to_meter' typo, 'inches2', unsupported 'nm' — raises a ValueError listing valid abbreviations.
Source
Thrown at conversions/length_conversion.py:121
ValueError: Invalid 'from_type' value: 'wrongUnit'.
Conversion abbreviations are: mm, cm, m, km, in, ft, yd, mi
"""
new_from = from_type.lower().rstrip("s")
new_from = TYPE_CONVERSION.get(new_from, new_from)
new_to = to_type.lower().rstrip("s")
new_to = TYPE_CONVERSION.get(new_to, new_to)
if new_from not in METRIC_CONVERSION:
msg = (
f"Invalid 'from_type' value: {from_type!r}.\n"
f"Conversion abbreviations are: {', '.join(METRIC_CONVERSION)}"
)
raise ValueError(msg)
if new_to not in METRIC_CONVERSION:
msg = (
f"Invalid 'to_type' value: {to_type!r}.\n"
f"Conversion abbreviations are: {', '.join(METRIC_CONVERSION)}"
)
raise ValueError(msg)
return (
value
* METRIC_CONVERSION[new_from].from_factor
* METRIC_CONVERSION[new_to].to_factor
)
if __name__ == "__main__":
import doctest
doctest.testmod()
View on GitHub (pinned to f5988cc097)
Solutions
- Use the documented abbreviations/full names for the target unit (mm, cm, m, km, in, ft, yd, mi)
- Validate both units once at startup against METRIC_CONVERSION keys after applying the library's normalization (lower + rstrip('s') + TYPE_CONVERSION)
- Restrict your UI's unit dropdown to exactly the supported set so invalid targets cannot be selected
Example fix
# before length_conversion(1, 'm', 'nmi') # ValueError # after length_conversion(1, 'm', 'mi') * 1.15078 # nautical miles via mi if needed
Defensive patterns
Strategy: validation
Validate before calling
from conversions.length_conversion import METRIC_CONVERSION, TYPE_CONVERSION
def norm(u: str) -> str:
u = u.lower().rstrip('s')
return TYPE_CONVERSION.get(u, u)
if norm(to_type) not in METRIC_CONVERSION:
raise ValueError(f"unsupported unit {to_type!r}; use {sorted(METRIC_CONVERSION)}") Prevention
- Validate both units in one normalization pass at startup
- Keep unit vocabularies in config aligned with the library's 8 supported units
- Remember normalization is lower() + rstrip('s') — anything beyond that needs your own mapping
When it happens
Trigger: length_conversion(4, 'inch', 'wrongUnit'), length_conversion(1, 'm', 'nmi') (nautical mile), or swapped-argument calls where a value/label lands in to_type.
Common situations: Unit pairs stored in separate config columns where the target column has dirtier data; plural forms not covered by rstrip('s') (e.g. 'inches' works, 'feet' works via table, but 'metres' fails); UI dropdowns that include units the library does not support.
Related errors
- Invalid 'from_type' value: {from_type!r}.\nConversion abbrev
- Incorrect 'from_type' or 'to_type' value: {from_type!r}, {to
- base must be >= 2
- Input value is not an integer
- Invalid value was passed to the function
AI-assisted analysis of TheAlgorithms/Python@f5988cc097 (2026-08-14).
Data as JSON: /api/errors/498c540d99691a16.
Report an issue: GitHub.