Author serhiy.storchaka
Recipients Mark.Shannon, eric.smith, serhiy.storchaka, taleinat, ztane
Date 2021-05-16.11:50:56
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1621165856.84.0.656841359056.issue28307@roundup.psfhosted.org>
In-reply-to
Content
PR 26160 adds support of %d, %i, %u, %o, %x, %X, %f, %e, %g, %F, %E, %G.

What is not supported:

* Formatting with a single value not wrapped into a 1-tuple (like in "%d bytes" % size). The behavior is non-trivial, it needs checking whether the value is a tuple or a mapping. It would require adding more opcodes and AST nodes and generating complex bytecode.
* Mapping keys (like in "%(name)s"). They are rarely used, and if used, it is not performance critical.
* Precision for integer formatting. Precision is not supported in new-style formatting of integers, and it is not trivial to reproduce this behavior.
* Variable width and precision (like in "%*.*s"). It is possible to support them, but the code would be pretty complex, and the benefit is small, because this feature is rarely used and is not performance critical.
* Format code %c. It is relatively rarely used.
* Length modifiers "h", "l" and "L" (like in "%ld"). They ignored in Python and I did not see them in real code. While supporting them is easy, it would requires adding more than one line of code, it is not worth it.
History
Date User Action Args
2021-05-16 11:50:56serhiy.storchakasetrecipients: + serhiy.storchaka, taleinat, eric.smith, Mark.Shannon, ztane
2021-05-16 11:50:56serhiy.storchakasetmessageid: <1621165856.84.0.656841359056.issue28307@roundup.psfhosted.org>
2021-05-16 11:50:56serhiy.storchakalinkissue28307 messages
2021-05-16 11:50:56serhiy.storchakacreate