[Python-Dev] transitioning from % to {} formatting (original) (raw)

Barry Warsaw barry at python.org
Wed Sep 30 17:31:23 CEST 2009

On Sep 30, 2009, at 11:22 AM, Steven Bethard wrote:

On Wed, Sep 30, 2009 at 5:21 AM, Barry Warsaw <barry at python.org> wrote:

On Sep 29, 2009, at 11:15 PM, Martin v. Löwis wrote:

I would propose that the format argument gets an argument name, according to the syntax it is written in. For PEP 3101 format, I would call the argument "format" (like the method name of the string type), i.e.

logging.Formatter( format="{asctime} - {name} - {levelname} - {message}") For the % formatting, I suggest "dicttemplate" (assuming that you have to use dictionary %(key)s style currently). The positional parameter would also mean dicttemplate, and would be deprecated (eventually requiring a keyword-only parameter). Although I hate the name 'dicttemplate', this seems like the best solution to me. Maybe it's good that 'dicttemplate' is so ugly though so that people will naturally prefer 'format' :). But I like this because there's not really any magic, it's explicit, and the decision is made by the coder at the call site. The implementation does not need to guess at all. Could you comment on what you think we should do when the parameter is not positional? As I mentioned upthread, in the case of logging.Formatter, it's already documented as taking the keyword parameter "fmt", so we'd have to use the name "fmt" for % formatting.

I'm okay with fmt==%-formatting and format=={}-formatting, but I'd
also be okay with transitioning 'fmt' to 'dicttemplate' or whatever.
I think the important thing is to be explicit in the method signature
which one you want (secondary would be trying to standardize this
across the stdlib).

-Barry

-------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 832 bytes Desc: This is a digitally signed message part URL: <http://mail.python.org/pipermail/python-dev/attachments/20090930/7a5ccc75/attachment.pgp>

More information about the Python-Dev mailing list