-
-
Notifications
You must be signed in to change notification settings - Fork 33.2k
Closed
Labels
topic-C-APItopic-unicodetype-featureA feature request or enhancementA feature request or enhancement
Description
PyUnicode_FromFormat() and several other functions like PyErr_Format() support a subset of printf-like formatting with some extensions to support Python objects. It is a very limited subset, for example %x is supported, but %lx and %X are not.
I propose to add support of more printf features:
- Support for conversion specifiers
o(octal) andX(uppercase hexadecimal). - Support for length modifiers
j(intmax_t) andt(ptrdiff_t). - Length modifiers are now applied to all integer conversions.
- Support for wchar_t C strings (
%lsand%lV). - Support for variable width and precision
*. - Support for flag
-(left alignment).
The following standard features are intentionally not implemented:
- Support for floating point formatting. It is very rare in error messages and reprs, and you always can use sprintf to a fixed buffer.
- Flags
#,(a space) and+.#is ambiguous for octals: should we use prefix0(as in C) or0o(as in Python)? The latter two flags are just rarely used (I initially implemented the support of them, but then removed, it is not worth). - Length modifiers
h(signed charandunsigned char) andhh(shortandunsigned short). Values of these types are automatically promoted tointorunsigned int, and you can use explicit conversion tointorunsigned intin case of ambiguity. %lc. Since%calready accepts integers outside of the range 0-255, and the difference betweenintandwint_tis subtle, I am not sure that that there is any value of supporting it.%n.- Width and precision are not supported in
%cand%p.
Unlike to printf, unsupported modifiers (like %lc or %10c) raise SystemError instead of be silently ignored. It will allow to add new features without breaking accidentally working code.
Metadata
Metadata
Assignees
Labels
topic-C-APItopic-unicodetype-featureA feature request or enhancementA feature request or enhancement