On 27Feb2012 07:13, Nick Coghlan wrote: | On Mon, Feb 27, 2012 at 5:23 AM, Eli Bendersky wrote: | >> It would be nice to call it something else than "printf-style | >> formatting". While it is certainly modelled on printf(), knowledge of C | >> or printf is not required to understand %-style formatting, nor even to | >> appreciate it. | > | > | > +1. The section is already titled "old string formatting operations" so if | > this name is acceptable it should be reused. If it's not, it should then be | > consistently changed everywhere. | | I deliberately chose printf-style as being value neutral (whereas | old-style vs new-style carries a heavier recommendation that you | should be using the new one). Sure you don't need to know printf to | understand it, but it needs *some* kind of name, and "printf-style" | acknowledges its roots. +1 here from me too: it _is_ printf in roots and several format specifiers (%d, %s etc). If you know printf you _immediately_ know a lot about what you can expect, and if you don't you know know a little about its roots. | Another value-neutral term is "mod-style", | which describes how it is invoked (and I believe we do use that in a | few places already). A -1 on "mod-style" from me. While it does use the "%" operator symbol, in no other way is it like the "mod" arithmetic operation. I think docs _should_ occasionally hint at preferred approaches. The new new formatting is a deliberate Python change. Without some rationale/editorial it flies in the face of the "one obvious way to do things" notion. It shouldn't be overdone, but neither should it be absent. Cheers, -- Cameron Simpson DoD#743 http://www.cskk.ezoshosting.com/cs/ Ignorance is preferable to error; and he is less remote from the truth who believes nothing, than he who believes what is wrong. - Thomas Jefferson

Ah, thanks, I knew there was another term that had a new-style counterpart: percent formatting vs brace formatting. -- Sent from my phone, thus the relative brevity :) On Feb 27, 2012 7:53 AM, "Georg Brandl" wrote:

On 02/26/2012 10:13 PM, Nick Coghlan wrote:

...

On Mon, Feb 27, 2012 at 5:23 AM, Eli Bendersky wrote:

...

It would be nice to call it something else than "printf-style

...

formatting". While it is certainly modelled on printf(), knowledge of C or printf is not required to understand %-style formatting, nor even to appreciate it.

+1. The section is already titled "old string formatting operations" so if this name is acceptable it should be reused. If it's not, it should then be consistently changed everywhere.

I deliberately chose printf-style as being value neutral (whereas old-style vs new-style carries a heavier recommendation that you should be using the new one). Sure you don't need to know printf to understand it, but it needs *some* kind of name, and "printf-style" acknowledges its roots. Another value-neutral term is "mod-style", which describes how it is invoked (and I believe we do use that in a few places already).

I've seen "percent-formatting", which is neutral, accurate and doesn't require any previous knowledge. (The new one could be "format-formatting" then, which is a tad awkward. :)

Georg

______________________________**_________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/**mailman/listinfo/python-devhttp://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/**mailman/options/python-dev/** ncoghlan%40gmail.comhttp://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com

On Sun, Feb 26, 2012 at 3:14 PM, Terry Reedy wrote:

On 2/26/2012 5:38 PM, Nick Coghlan wrote:

...

Ah, thanks, I knew there was another term that had a new-style counterpart: percent formatting vs brace formatting.

Hooray! Exact parallel and value-neutral.

Can we stop it with the "political correctness" already? The old style is best named printf-style formatting because that's the origin of the format language, and there are many other programming languages that support the same formatting language (with minor variations). I care less about what we call the new style -- "new style" or "format method" both work for me. I also would like to suggest that, even if the reality is that we can't deprecate it today, *eventually*, at *some* *distant* point in the future we ought to start deprecating printf-style formatting -- it really does have a couple of nasty traps that keep catching people unawares. In the mean time it doesn't hurt to use terms that make people ever so slightly uneasy with using the old style for new code, while also committing to not throwing it out until Python 4 comes around. That said, for consistency's sake, if you add formatting code to an existing module that uses the old style, please stick to the old style. And to avoid disasters, also please don't go on a library-wide rampage of wholesale conversions. The time to start using the new formatting is when writing new modules or packages, or possibly when doing a major refactoring/upgrade of an existing module or package. One thing I'd like to see happening regardless is support for new-style formatting in the logging module. It's a little tricky to think how that would work, alas -- should this be a property of the logger or of the call? -- --Guido van Rossum (python.org/~guido)

On 26/02/2012 23:33, Guido van Rossum wrote:

On Sun, Feb 26, 2012 at 3:14 PM, Terry Reedy wrote:

...

On 2/26/2012 5:38 PM, Nick Coghlan wrote:

...

Ah, thanks, I knew there was another term that had a new-style counterpart: percent formatting vs brace formatting.

Hooray! Exact parallel and value-neutral.

Can we stop it with the "political correctness" already? The old style is best named printf-style formatting because that's the origin of the format language, and there are many other programming languages that support the same formatting language (with minor variations). I care less about what we call the new style -- "new style" or "format method" both work for me.

I also would like to suggest that, even if the reality is that we can't deprecate it today, *eventually*, at *some* *distant* point in the future we ought to start deprecating printf-style formatting -- it really does have a couple of nasty traps that keep catching people unawares. In the mean time it doesn't hurt to use terms that make people ever so slightly uneasy with using the old style for new code, while also committing to not throwing it out until Python 4 comes around.

That said, for consistency's sake, if you add formatting code to an existing module that uses the old style, please stick to the old style. And to avoid disasters, also please don't go on a library-wide rampage of wholesale conversions. The time to start using the new formatting is when writing new modules or packages, or possibly when doing a major refactoring/upgrade of an existing module or package.

One thing I'd like to see happening regardless is support for new-style formatting in the logging module. It's a little tricky to think how that would work, alas -- should this be a property of the logger or of the call?

Just thinking out loud that a tool along the lines of 2to3 aimed specifically at changing string formatting would be some encouragement for people to switch. Maybe a project for someone being looked after on the mentors ml? -- Cheers. Mark Lawrence.