String formatting

Monty implements CPython 3.14's format mini-language for f-string interpolations and str.format() replacement fields. str.format() supports positional and keyword fields, automatic and manual numbering, attribute and item access, !s / !r / !a conversions, nested replacement fields in format specs, and escaped braces.

Attribute access is limited to lookups that complete inside the sandbox. If a replacement field needs a host operation, such as '{0.environ}'.format(os), Monty raises NotImplementedError: str.format attribute access cannot suspend instead of returning the attribute as CPython does.

The other CPython formatting entry points are not implemented:

• The format() builtin raises NameError, and str.format_map() raises AttributeError (see builtins.md).
• Printf-style % formatting ('%5.3f' % math.pi, '%s %s' % (a, b)) is not implemented. str has no __mod__, so str % value raises TypeError: unsupported operand type(s) for %: 'str' and '...'. Use an f-string instead.

Custom __format__

f-strings and str.format() dispatch to a type's __format__ only for date, datetime and time, which interpret the spec as a strftime string (f'{dt:%Y-%m-%d}' or '{:%Y-%m-%d}'.format(dt)); see datetime.md. There is no general __format__ protocol: user classes can't customise formatting (see classes.md), and all other types use the builtin mini-language formatter. A format spec on a user-class instance is silently applied to str(obj) (f'{obj:>10}' pads), where CPython raises TypeError: unsupported format string passed to Foo.__format__.

The n type uses the C locale only

n always behaves as in the C/POSIX locale (Monty has no locale support): like d for integers and g for floats, with no digit grouping. CPython under a grouping locale would insert locale-specific separators; Monty never does.

repr of non-printable Unicode

repr escapes non-printable code points via the unicode-general-category crate, whose Unicode version may lag CPython's, so a code point assigned in a newer Unicode release than the crate ships could be escaped by Monty while CPython prints it literally, or the reverse. Common text is unaffected.

Width / precision bounds

• A width or precision whose decimal value overflows usize raises SyntaxError: Invalid format specifier '...': width or precision overflows usize in a literal f-string spec. Runtime specs, including str.format(), raise ValueError instead, with an additional for object of type '...' suffix.
• Very large widths/precisions are additionally bounded by the resource tracker; see resource_limits.md.

When spec errors are raised

CPython validates a static (literal) f-string spec only when the f-string executes, so a malformed spec in dead code never raises. Monty validates literal f-string specs at compile time for the structurally-malformed cases: two or more trailing characters after the type field (f'{1:kk}', f'{1:10xyz}') and usize overflow, raising SyntaxError instead of CPython's runtime ValueError. The message text otherwise matches, minus CPython's for object of type '...' suffix, which needs the runtime value type. Specs whose error is value-type-dependent or only resolvable at format time (Unknown format code 'k', the Cannot specify … grouping conflicts, and Format specifier missing precision) are deferred to runtime and raise the exact CPython ValueError, as do all dynamically-built specs (f'{1:{spec}}') and all str.format() specs.