I was looking at this jokey page on the evolution of programming language syntax -- http://alan.dipert.org/post/153430634/the-march-of-progress -- and it made me think about where Python is now. The Python 2 version of the example from the page is print "%10.2f" % x and the Python 3 is print("{:10.2f}".format(x)) Personally, I prefer the new style {} formatting to the old % formatting, but it is pretty busy when you want to do a print and format in one step. Why not add a printf function to the built-ins, so you could just write printf("{:10.2f}", x) Of course, writing a printf function for oneself is trivial and "not every three line function needs to be a built-in," but I do feel like this would be a win for Python's legibility. What do you all think? -- Carl Johnson
On 12May2012 14:49, Carl M. Johnson <cmjohnson.mailinglist@gmail.com> wrote: | I was looking at this jokey page on the evolution of programming language syntax -- http://alan.dipert.org/post/153430634/the-march-of-progress -- and it made me think about where Python is now. The Python 2 version of the example from the page is | | print "%10.2f" % x | | and the Python 3 is | | print("{:10.2f}".format(x)) | | Personally, I prefer the new style {} formatting to the old % | formatting, but it is pretty busy when you want to do a print and | format in one step. Why not add a printf function to the built-ins, | so you could just write | | printf("{:10.2f}", x) | | Of course, writing a printf function for oneself is trivial and "not | every three line function needs to be a built-in," but I do feel like | this would be a win for Python's legibility. I'm -1 on it: - as you say, it could be a three line function - %-formatting isn't going away - neither %-formatting nor {}-formatting is anything to do with the print statement; they are both string actions So the printf idea does not achieve anything anyway. Observe my Python 3.2: [/home/cameron]janus*> python3.2 Python 3.2.2 (default, May 2 2012, 09:04:59) [GCC 4.5.3] on linux2 Type "help", "copyright", "credits" or "license" for more information.
Printf isn't needed. Cheers, -- Cameron Simpson <cs@zip.com.au> DoD#743 http://www.cskk.ezoshosting.com/cs/ Senior ego adepto, ocius ego eram.
On May 12, 2012, at 3:50 PM, Cameron Simpson wrote:
Well, if that's the solution, why do we even have .format in the first place? I know there are a lot of people who still prefer % formatting, but I personally never liked it, and I prefer not to use it if I have any choice about it. But that's neither here nor there. My question is, being that we have .format, why not make it easier to use?
Carl M. Johnson wrote:
Define "easier to use". Calling a method and passing its output to print seems to be pretty easy to me. The major issue with printf is that it prints AND formats. That means you can't easily capture its output. A simpler approach is to have one function that handles the printing, and another function (or possibly a choice of multiple functions) that handles the formatting, then simply pass the output of the second to the first. That is to say, multiple simple tools that do one thing each are simpler *and* more flexible than a single tool to do multiple things: a hammer and a wrench together are less complex than a combination hammer-wrench, and you can do more with them as separate tools than as a combo. -- Steven
On 2012-05-13, at 09:22 , Steven D'Aprano wrote:
Define "easier to use". Calling a method and passing its output to print seems to be pretty easy to me.
The major issue with printf is that it prints AND formats. That means you can't easily capture its output. A simpler approach is to have one function that handles the printing, and another function (or possibly a choice of multiple functions) that handles the formatting, then simply pass the output of the second to the first.
An other option is to have a formatting function similar to Common Lisp's format[0]: it formats a string and * If provided with a stream (or stream-like) argument writes the formatted string to the stream and returns `nil` * Otherwise returns the formatted string The function formats and prints, but capturing the output (to a non-standard stream or to a string) is trivial. [0] http://www.lispworks.com/documentation/HyperSpec/Body/f_format.htm#format
Cameron Simpson wrote:
Printf isn't needed.
Agreed. printf does two things, formatting and printing, and Python can already do both. There's no point in a format-then-print function when you can just format then print. However a lightweight alternative to regexes, something similar to scanf only safe, might be a nice idea. You can simulate scanf with regexes, but of course that's hardly lightweight. (But now I'm indulging in idle speculation, not a serious proposal.) -- Steven
On 2012-05-13, at 02:49 , Carl M. Johnson wrote:
I'm −1 on two counts personally: 1. Even with Python 3's slightly more verbose string formatting, I don't think there's much (if any) gain in having a builtin merging print and format 2. If I see a function called `printf` (or with `printf` pas part of its name), I expect it to use printf-style format strings (that is, Python 2-style formatting). A function called printf with new-style format string would be far more confusing than the current situation, I think.
On Sun, May 13, 2012 at 10:49 AM, Carl M. Johnson <cmjohnson.mailinglist@gmail.com> wrote:
The main reason the format() builtin exists is to easily format single fields:
The new formatting system doesn't scale down as well as the old one, so "format a single field value with no surrounding text" is handled as a special case.
The problem is that you have two competing uses for your arguments - "print" wants to accept "file", "end", etc, while format() wants to accept *args and **kwds). It's better to keep the two separate and allow people to compose them as they wish. For myself, aside from temporary debugging messages, I rarely call "print" directly in any non-trivial code - instead I'll have a "display" utility module that tweaks things appropriately for the specific application. Maybe it will redirect to logging, maybe it will print directly to a stream or to a file - the utility module gives me a single point of control without having to change the rest of the script. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On 12May2012 14:49, Carl M. Johnson <cmjohnson.mailinglist@gmail.com> wrote: | I was looking at this jokey page on the evolution of programming language syntax -- http://alan.dipert.org/post/153430634/the-march-of-progress -- and it made me think about where Python is now. The Python 2 version of the example from the page is | | print "%10.2f" % x | | and the Python 3 is | | print("{:10.2f}".format(x)) | | Personally, I prefer the new style {} formatting to the old % | formatting, but it is pretty busy when you want to do a print and | format in one step. Why not add a printf function to the built-ins, | so you could just write | | printf("{:10.2f}", x) | | Of course, writing a printf function for oneself is trivial and "not | every three line function needs to be a built-in," but I do feel like | this would be a win for Python's legibility. I'm -1 on it: - as you say, it could be a three line function - %-formatting isn't going away - neither %-formatting nor {}-formatting is anything to do with the print statement; they are both string actions So the printf idea does not achieve anything anyway. Observe my Python 3.2: [/home/cameron]janus*> python3.2 Python 3.2.2 (default, May 2 2012, 09:04:59) [GCC 4.5.3] on linux2 Type "help", "copyright", "credits" or "license" for more information.
Printf isn't needed. Cheers, -- Cameron Simpson <cs@zip.com.au> DoD#743 http://www.cskk.ezoshosting.com/cs/ Senior ego adepto, ocius ego eram.
On May 12, 2012, at 3:50 PM, Cameron Simpson wrote:
Well, if that's the solution, why do we even have .format in the first place? I know there are a lot of people who still prefer % formatting, but I personally never liked it, and I prefer not to use it if I have any choice about it. But that's neither here nor there. My question is, being that we have .format, why not make it easier to use?
Carl M. Johnson wrote:
Define "easier to use". Calling a method and passing its output to print seems to be pretty easy to me. The major issue with printf is that it prints AND formats. That means you can't easily capture its output. A simpler approach is to have one function that handles the printing, and another function (or possibly a choice of multiple functions) that handles the formatting, then simply pass the output of the second to the first. That is to say, multiple simple tools that do one thing each are simpler *and* more flexible than a single tool to do multiple things: a hammer and a wrench together are less complex than a combination hammer-wrench, and you can do more with them as separate tools than as a combo. -- Steven
On 2012-05-13, at 09:22 , Steven D'Aprano wrote:
Define "easier to use". Calling a method and passing its output to print seems to be pretty easy to me.
The major issue with printf is that it prints AND formats. That means you can't easily capture its output. A simpler approach is to have one function that handles the printing, and another function (or possibly a choice of multiple functions) that handles the formatting, then simply pass the output of the second to the first.
An other option is to have a formatting function similar to Common Lisp's format[0]: it formats a string and * If provided with a stream (or stream-like) argument writes the formatted string to the stream and returns `nil` * Otherwise returns the formatted string The function formats and prints, but capturing the output (to a non-standard stream or to a string) is trivial. [0] http://www.lispworks.com/documentation/HyperSpec/Body/f_format.htm#format
Cameron Simpson wrote:
Printf isn't needed.
Agreed. printf does two things, formatting and printing, and Python can already do both. There's no point in a format-then-print function when you can just format then print. However a lightweight alternative to regexes, something similar to scanf only safe, might be a nice idea. You can simulate scanf with regexes, but of course that's hardly lightweight. (But now I'm indulging in idle speculation, not a serious proposal.) -- Steven
On 2012-05-13, at 02:49 , Carl M. Johnson wrote:
I'm −1 on two counts personally: 1. Even with Python 3's slightly more verbose string formatting, I don't think there's much (if any) gain in having a builtin merging print and format 2. If I see a function called `printf` (or with `printf` pas part of its name), I expect it to use printf-style format strings (that is, Python 2-style formatting). A function called printf with new-style format string would be far more confusing than the current situation, I think.
On Sun, May 13, 2012 at 10:49 AM, Carl M. Johnson <cmjohnson.mailinglist@gmail.com> wrote:
The main reason the format() builtin exists is to easily format single fields:
The new formatting system doesn't scale down as well as the old one, so "format a single field value with no surrounding text" is handled as a special case.
The problem is that you have two competing uses for your arguments - "print" wants to accept "file", "end", etc, while format() wants to accept *args and **kwds). It's better to keep the two separate and allow people to compose them as they wish. For myself, aside from temporary debugging messages, I rarely call "print" directly in any non-trivial code - instead I'll have a "display" utility module that tweaks things appropriately for the specific application. Maybe it will redirect to logging, maybe it will print directly to a stream or to a file - the utility module gives me a single point of control without having to change the rest of the script. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
participants (5)
-
Cameron Simpson -
Carl M. Johnson -
Masklinn -
Nick Coghlan -
Steven D'Aprano