[Python-Dev] transitioning from % to {} formatting

Vinay Sajip vinay_sajip at yahoo.co.uk
Fri Oct 2 00:39:03 CEST 2009

Nick Coghlan <ncoghlan <at> gmail.com> writes:

> I believe classes like fmt_braces/fmt_dollar/fmt_percent will be part of
> a solution, but they aren't a complete solution on their own. (Naming
> the three major string formatting techniques by the key symbols involved
> is a really good idea though)
> The two major problems with them:
> 1. It's easy to inadvertently convert them back to normal strings. If a
> formatting API even calls "str" on the format string then we end up with
> a problem (and switching to containment instead of inheritance doesn't
> really help, since all objects implement __str__).
> 2. They don't help with APIs that expect a percent-formatted string and
> do more with it than just pass it to str.__mod__ (e.g. inspecting it for
> particular values such as '%(asctime)s')

Good point as far as the general case is concerned, though it's perhaps not that
critical for logging. By which I mean, it's not unreasonable for
Formatter.__init__ to grow a "style" keyword parameter which determines whether
it uses %-, {}- or $-formatting. Then the formatter can look for '%(asctime)s',
'{asctime}' or '$asctime' according to the style. 

Just to clarify - LogRecord.getMessage *will* call str() on a message object if
it's not a string or Unicode object. For 2.x the logic is

if type(msg) not in (unicode, str):
    msg = str(msg)

and for 3.x the check is for isinstance(msg, str).

> Still, it's worth considering adding the three fmt_* classes to the
> string module to see how far they can get us in adapting the formats for
> different APIs.
> Note that I don't think these concepts are fully baked yet, so we
> shouldn't do anything in a hurry - and anything that does happen should
> be via a PEP so we can flush out more issues.

Yes, we're just "kicking the tires" on the various ideas. There are things still
a bit up in the air such as what happens when pickling and sending to an older
version of Python, etc. which still need to be resolved for logging, at least.


Vinay Sajip

More information about the Python-Dev mailing list