Re: [Python-Dev] cpython (3.2): Issue #14123: Explicitly mention that old style % string formatting has caveats
On Sun, 26 Feb 2012 19:50:10 +0100 martin@v.loewis.de wrote:
- The formatting operations described here are obsolete and may go away in future - versions of Python. Use the new :ref:`string-formatting` in new code. + The formatting operations described here are modelled on C's printf() + syntax. They only support formatting of certain builtin types. The + use of a binary operator means that care may be needed in order to + format tuples and dictionaries correctly. As the new + :ref:`string-formatting` syntax is more flexible and handles tuples and + dictionaries naturally, it is recommended for new code. However, there + are no current plans to deprecate printf-style formatting.
Please consider just deleting the last sentence. Documentation is meant for users (often new users) and not core devs. As such, I just don't see what it adds. If the aim to to document this intent somewhere, a PEP would be a better place than the formal documentation.
I'd rather leave the last sentence, and delete the penultimate sentence. The last sentence is useful information to the end user ("we will not deprecate printf-style formatting, so there is no need to change existing code"). I'd drop the penultimate sentence because there is no consensus that it is a useful recommendation (and it is certainly not a statement of fact).
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. Regards Antoine.
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. Eli
On Mon, Feb 27, 2012 at 5:23 AM, Eli Bendersky <eliben@gmail.com> 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 didn't actually expect that paragraph to be incorporated wholesale into the docs - it was intended as a discussion starter, not a finished product. Aside from the last two sentences, the other big problem with it is that print-style formatting *does* support formatting arbitrary objects, they're just forced to go through type coercions whereas .format() allows objects to define their own formatting specifiers (such as datetime with strftime strings). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On 27Feb2012 07:13, Nick Coghlan <ncoghlan@gmail.com> wrote: | On Mon, Feb 27, 2012 at 5:23 AM, Eli Bendersky <eliben@gmail.com> 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 <cs@zip.com.au> 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
On 02/26/2012 10:13 PM, Nick Coghlan wrote:
On Mon, Feb 27, 2012 at 5:23 AM, Eli Bendersky<eliben@gmail.com> 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
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" <g.brandl@gmx.net> wrote:
On 02/26/2012 10:13 PM, Nick Coghlan wrote:
On Mon, Feb 27, 2012 at 5:23 AM, Eli Bendersky<eliben@gmail.com> 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-dev<http://mail.python.org/mailman/listinfo/python-dev> Unsubscribe: http://mail.python.org/**mailman/options/python-dev/** ncoghlan%40gmail.com<http://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com>
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. -- Terry Jan Reedy
On Sun, Feb 26, 2012 at 3:14 PM, Terry Reedy <tjreedy@udel.edu> 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 26Feb2012 15:33, Guido van Rossum <guido@python.org> wrote: | 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? Surely the call? The caller doesn't necessarily know anything about the loggers in play, so if a logger sprouts different message formating syntax the caller is hosed. -- Cameron Simpson <cs@zip.com.au> DoD#743 http://www.cskk.ezoshosting.com/cs/ A Master is someone who started before you did. - Gary Zukav
On 26/02/2012 23:33, Guido van Rossum wrote:
On Sun, Feb 26, 2012 at 3:14 PM, Terry Reedy<tjreedy@udel.edu> 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.
On 02/26/2012 03:33 PM, Guido van Rossum wrote:
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?
There already is some support. logging.Formatter objects can be initialized with a "style" parameter, making this a property of the logger. (New in 3.2.) http://docs.python.org/py3k/library/logging.html#formatter-objects Is that what you had in mind? //arry/
On Mon, Feb 27, 2012 at 5:54 AM, Antoine Pitrou <solipsis@pitrou.net> 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. Calling it "printf-style" ties it in with its origins just as the term "regex" does for the 're' module. There are printf-derived features in quite a few high level languages; they may differ somewhat (Pike's sprintf() can do columnar displays; PHP's vsprintf takes an array, not some weird and mythical varargs token), but in their basics they will be similar. The name is worth keeping. Chris Angelico
participants (10)
-
Antoine Pitrou -
Cameron Simpson -
Chris Angelico -
Eli Bendersky -
Georg Brandl -
Guido van Rossum -
Larry Hastings -
Mark Lawrence -
Nick Coghlan -
Terry Reedy