This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: string formatting quirk using %.%
Type: behavior Stage:
Components: Interpreter Core Versions:
process
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: Nosy List: blop, georg.brandl, gvanrossum
Priority: normal Keywords:

Created on 2008-08-07 13:33 by blop, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
unnamed blop, 2008-08-07 17:19
Messages (4)
msg70822 - (view) Author: nadav (blop) * Date: 2008-08-07 13:33
>>> "%.%s" % ()
'%s'
>>> "%(a).%(b)s" % dict(a=2)
'%(b)s'
>>> "%(a).%(b)s" % dict(a=2, b=3)
'%(b)s'
>>> "%(a).%(b)s" % dict()
Traceback (most recent call last):
  File "<pyshell#6>", line 1, in -toplevel-
    "%(a).%(b)s" % dict()
KeyError: 'a'

this is counter intuitive and cannot be deduced from the documentation.
msg70838 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2008-08-07 16:51
It's straightforward if you consider the implementation of the
requirement that %% renders a single percent sign: the second % is
parsed just like any other formatting code (i, d, f, etc.) and the stuff
between the first % and the formatting code is treated completely uniformly.
msg70841 - (view) Author: nadav (blop) * Date: 2008-08-07 17:19
The main problem with this is that the following code does not make any
sense:
"%(a)%" % dict(a=3)

It has no semantic meaning (take the dictionary paramater a, and do nothing
with it).
It must be a user bug (except in very wierd cases).

I agree that when I consider the implementaion, it makes sense, but as a
python user, this behavior is really non-intuitive.

2008/8/7 Guido van Rossum <report@bugs.python.org>

>
> Guido van Rossum <guido@python.org> added the comment:
>
> It's straightforward if you consider the implementation of the
> requirement that %% renders a single percent sign: the second % is
> parsed just like any other formatting code (i, d, f, etc.) and the stuff
> between the first % and the formatting code is treated completely
> uniformly.
>
> ----------
> nosy: +gvanrossum
> resolution:  -> rejected
> status: open -> closed
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue3516>
> _______________________________________
>
msg70845 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2008-08-07 18:01
I'd rather see it this way: It is a programming error if a format string
contains a reference to a nonexisting dictionary key, no matter what
formatting specifier is used. The implementation is quite consistent here.
History
Date User Action Args
2022-04-11 14:56:37adminsetgithub: 47766
2008-08-07 18:01:12georg.brandlsetnosy: + georg.brandl
messages: + msg70845
2008-08-07 17:19:29blopsetfiles: + unnamed
messages: + msg70841
2008-08-07 16:51:14gvanrossumsetstatus: open -> closed
resolution: rejected
messages: + msg70838
nosy: + gvanrossum
2008-08-07 13:33:05blopcreate