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.

Author terry.reedy
Recipients ebehar, eric.araujo, eric.smith, ezio.melotti, gruszczy, r.david.murray, rhettinger, terry.reedy
Date 2010-08-11.19:51:58
SpamBayes Score 1.70877e-09
Marked as misclassified No
Message-id <>
I understand now that new methods, as opposed to changed methods, are allowed.

I agree with Eric that this seems more like a convinience rather than absolute necessity, and that the doc should be augmented.

The doc for vformat (which I admit I had not noticed before) says it is exposed just for this case:

"vformat(format_string, args, kwargs) 
This function does the actual work of formatting. It is exposed as a separate function for cases where you want to pass in a predefined dictionary of arguments, rather than unpacking and repacking the dictionary as individual arguments using the *args and **kwds syntax."

'Dictionary' should be replaced with 'mapping'.

string.Formatter.format is documented as "just a wrapper that calls vformat(). Is the same effectively true of str.format also?

If .format_map (I prefer shorted names) is added as a convenience str method, particularly for matching current %-formatting use, I think it should take just one parameter, mapping. I presume it could implemented as a wrapper for .vformat (or whatever internal function .vformat calls).

str.format_map(map) == string.Format.vformat(formstring, (), map)

More complicated, mixed cases can use the explict lookup with map arg.
Date User Action Args
2010-08-11 19:52:00terry.reedysetrecipients: + terry.reedy, rhettinger, eric.smith, ezio.melotti, eric.araujo, r.david.murray, gruszczy, ebehar
2010-08-11 19:51:59terry.reedysetmessageid: <>
2010-08-11 19:51:58terry.reedylinkissue6081 messages
2010-08-11 19:51:58terry.reedycreate