parse 1.22.2 - Signed Decimals and Uppercase Format Types

The Python package r1chardj0n3s/parse published tag 1.22.2 on 18 September 2026. For field extraction the important fix is {:F}, where a negative Decimal used to return no match and a job could drop the value while keeping the row. The same tag accepts uppercase format letters E, G, and X, which str.format emits and earlier releases rejected with ValueError.

The full release notes and downloads are on the GitHub release page. The tag is a final release. The compare range against 1.22.1 contains two pull requests. Both are first contributions, from Labib-Bin-Salam and Sreekant13.

Pull request 230 registers the type letters E, G, and X. Lowercase e, g, and x already parsed. The uppercase letter in the pattern raised ValueError with the text format spec 'X' not recognised, and the same text for E and G.

The matched text was already legal. An e or g pattern already matches an exponent written with E, because that class is [eE]. An x pattern already matches hex digits A through F, because that class is [0-9a-fA-F]. What failed was the type letter itself. E, G, and X were absent from ALLOWED_TYPES and from is_numeric, and the dispatch branches named only the lowercase letters. A pattern copied from a str.format spec never reached the regex.

Ordinary formatted numbers hit it. format(255, "X") is FF. format(1234.5, "E") is 1.234500E+03. format(1234567.0, "G") is 1.23457E+06. On the previous tag, {:X}, {:E}, and {:G} rejected those strings. With G, the type letter is G and the rendered text can still contain an uppercase E in the exponent. The exponent class already allowed that E. The type letter did not.

The patch adds the three letters and sends them through the same handlers as e, g, and x. Signs, nan, inf, and a 0x prefix on the hex type follow the lowercase forms. parse("{:X}", "FF") returns 255. parse("{:E}", "-1.234500E+03") returns -1234.5. A named field works the same way: parse("color #{code:X}", "color #1A2B3C") binds code to 1715004. F stays the Decimal type.

README.rst lists the three letters in the format type table. tests/test_parse.py adds cases under test_numbers that format a value and parse it back. A wrapper that rewrote E, G, and X to lowercase before calling parse can leave those three letters as written.

Negative Decimals failed as a missed match. Pull request 250 fixes issue 249. {:F} is the Decimal specifier. It could not parse a negative number because F was missing from the is_numeric set. Without that membership, the regex never gained the shared sign prefix [-+ ]? that every other numeric type receives.

parse("{:F}", "-2.5") returned None. parse("{:f}", "-2.5") returned the float -2.5. A loader that skips None fields drops a negative quantity or a signed balance and still reports a parsed row.

The edit is one character in that set. The old member string is n%fegdobxEGX. Inserting F beside f produces n%fFegdobxEGX. A leading minus, plus, or space is then legal on {:F} the same way it already was on {:f}. Conversion after a match is unchanged. F had been a type for a long time, and the sign prefix work never listed it. Positive Decimals parse as before. A leading minus now returns a Decimal instead of None.

The same pull request makes {:f} and {:F} accept nan and inf. {:e}, {:E}, {:g}, and {:G} already did. Python prints those sentinels with a fixed point spec: "{:f}".format(float("nan")) equals nan. A CSV cell or a log token written that way did not match {:f} or {:F} on 1.22.1.

The added alternation is nan|NAN|inf|INF. It sits inside a group that does not capture, with the sign prefix [-+ ]? in front of the whole group. A bare extra branch would bind the sign to the first alternative only, and negative numbers would stop matching. That would undo the Decimal sign fix. e and g already kept the sign outside the rest of the number. f and F did not, so they need the group.

test_numbers gains cases for a signed Decimal and for nan and inf on both f and F. Those cases fail on the previous tag. test_numbered stores the exact regex text for {:f}, so that assertion changes with the new group. The pull request description reports 97 passed and 1 skipped.

The release notes list nothing else. No dependency change, no command line flag, and no migration list. Two shifts are worth a check before a pin bump. A {:F} pattern that used None to mean “leading minus, skip the field” now returns a Decimal. Code that caught ValueError for spec letters E, G, or X no longer gets that error. F remains the Decimal type.