This looks like a bug in the way the %-formatting code
works or is it a feature ?

>>> '%s %(a)s' % {'a': 'xyz'}
"{'a': 'xyz'} xyz"

>>> u'%s %(a)s' % {'a': 'xyz'}
u"{'a': 'xyz'} xyz"

Note that both strings and Unicode are affected.

Python 2.3 and 2.4 also show this behavior.

I would have expected an exception or the %-formatter
simply ignoring the first %s.

Logged In: YES 
user_id=1185570

It looks as though it's a feature... The first %s will print
the whole dictionary as a string, the second, only that
value looked up by the key.

Logged In: YES 
user_id=849994

The library ref specifies that if a dict is supplied, the
format specifiers MUST include a mapping key, so the right
thing to do would be to raise an exception.

Is it worth breaking backwards compatibility, Martin?

Logged In: YES 
user_id=21627

IMO, it's correct to break backwards compatibility, as the
current behaviour clearly violates the spec; I'm not sure
whether it's good to break the behaviour *now* (i.e. with no
further betas before the release of 2.5).

Deferring to the release manager.

Logged In: YES 
user_id=11375

So, what should '%s' % {} do?  Should it be 1) '{}' or 2) an
error because the argument is a mapping but the format
specifier doesn't have a '(key)'?

I've attached a draft patch that fixes stringobject.c; if
the approach is deemed OK, I'll apply it to unicodeobject.c,
too.  PyString_Format() records the type of argument being
processed (a tuple or a mapping) and raises ValueError if
you mix them, at the cost of two extra comparisons for each
format specifier processed.  This preserves the current
behaviour of '%s' % dictionary.

Questions: 1) is the approach reasonably clear?  2) are the
additional two comparisons unacceptably slow?  3) Is
ValueError the right exception?  4) can someone come up with
a better exception message than "both keyed and unkeyed
format specifiers used"?

Logged In: YES 
user_id=44345

Looks okay to me, though why is the FORMAT_TYPE_UNKNOWN test
necessary in the second case but not the first?

Logged In: YES 
user_id=38388

The patch looks OK.

I'd make it a TypeError and use "cannot use positional and
named formatting parameters at the same time" as message.

Thanks.

Logged In: YES 
user_id=764593

Just a bit of encouragement for checking consistency like 
this; the explicit error message would have helped with a 
mistake I made earlier today.  For one of several keys, I 
mistyped it as "(%key)s", and a message about "not enough 
values" just didn't make sense.

Logged In: YES 
user_id=38388

Should this patch be applied to the 2.5 branch ?

And if so, before or after the release of 2.5 ?

Logged In: YES 
user_id=849994

I'd say before 2.5 final...

I'm happy for this to be applied for 2.5.1. I don't have time to do it myself for a few days, though, so feel free to beat me to it.

The patch shouldn't be applied as it stands, though, because it's not complete; similiar changes need to be made to the Unicode type, for a start.

To answer Skip's question: I don't remember the logic of the format code.  I think the FORMAT_TYPE_UNKNOWN check may be unnecessary; the code could just always do format_type = _TUPLE, occasionally doing a redundant assignment (but who cares)?

I don't think I'll have any chance to work on this; PyCon is keeping me busy, and the mailbox bugs will take priority for me.

I'm attaching a new version of this which includes AMK's string patch
ported over to unicode.

Any objections to my committing this to the trunk?  Should it also go in
for the next 2.5 release?

This probably won't be important anymore now that we have str.format()...

Sean, why don't you just check in the patch ?

Then we can close the bug.

Georg, the fact that we have an alternative method for string formatting
doesn't mean that it's ok for Python to hide error using the prevailing
method of string formatting.

I didn't want to imply that, but seeing that nobody cared about it for
so long I hadn't much hope for the future... ;)

I guess the patch was just forgotten after the 2.5 release was out.

I've added a 2.6 tag and assigned the patch to Sean.

Confirmed in trunk and py3k. How about changing this for 3.1?

The patch incorrectly raises an exception for:
'%(a)s %%' % {'a':'xyz'}

I'll look into fixing it.

Too late for 2.x and 3.1.

Updated patch against py3k. Fixing last reported issue with
'%(a)s %%' % {'a':'xyz'}

Updated patch to capture another patological case:
'%(a)s %' % {'a':'xyz'} - incomplete formatter at the end of the line

Updated patch: some tests added.

Eric, would you like an update PR for this?

I unassigned myself from this a few months ago. If someone wants to fix it, I'm not opposed. But the issue is 12 years old and doesn't cause any real problems as far as I can see, so it's hard to get excited about it. And as we've seen there are a lot of corner cases. I'd hate to make things worse.

Ah, sorry Eric, I misread that change as you assigning this to yourself.

[Eric V. Smith]
>  But the issue is 12 years old and doesn't cause any real problems 
> as far as I can see, so it's hard to get excited about it. 
> And as we've seen there are a lot of corner cases. I'd hate to 
> make things worse.

I ooncur with Eric and think this ought to be closed. It is a oddity but has proven itself to be harmless in the wild.  At this point in the life cycle of %-formatting it would be prudent to value stability over niggling behavior changes.