Comments on: Printing in Python 3.0 http://efford.org/blog/archives/34 Random musings on Python, software engineering, the web & other stuff Thu, 21 Aug 2008 14:42:17 +0000 http://wordpress.org/?v=2.0.4 by: Nick http://efford.org/blog/archives/34#comment-30289 Tue, 01 Apr 2008 13:45:16 +0000 http://efford.org/blog/archives/34#comment-30289 Some good points Jayce. I expect that plenty of folk will be opposed to the idea of introducing a new built-in, for understandable reasons. However, in a language that prides itself on clarity, and that is prepared to break backwards compatibility to the point that "hello world" no longer works in order to achieve this, I confess to being a little disappointing that a more direct, less clumsy approach to formatted printing isn't yet available. Don't get me wrong; there's a number of things about the new approach to string formatting that I like. It is more flexible and powerful, for one. And I think I prefer {0}, {1}, etc, as a placeholder syntax. What I don't really like is the relative unreadability of code like this: print("Content-type: {0[.mp4]}".format(mimetypes.types_map)) OK, you can rewrite this as format_string = "Content-type: {0[.mp4]}" print(format_string.format(mimetypes.types_map)) But I think a printf in this case is even easier to read. Some good points Jayce. I expect that plenty of folk will be opposed to the idea of introducing a new built-in, for understandable reasons.

However, in a language that prides itself on clarity, and that is prepared to break backwards compatibility to the point that “hello world” no longer works in order to achieve this, I confess to being a little disappointing that a more direct, less clumsy approach to formatted printing isn’t yet available.

Don’t get me wrong; there’s a number of things about the new approach to string formatting that I like. It is more flexible and powerful, for one. And I think I prefer {0}, {1}, etc, as a placeholder syntax. What I don’t really like is the relative unreadability of code like this:

print(”Content-type: {0[.mp4]}”.format(mimetypes.types_map))

OK, you can rewrite this as

format_string = “Content-type: {0[.mp4]}”
print(format_string.format(mimetypes.types_map))

But I think a printf in this case is even easier to read.

]]> by: Jayce http://efford.org/blog/archives/34#comment-30116 Sun, 30 Mar 2008 23:34:25 +0000 http://efford.org/blog/archives/34#comment-30116 Ideally, to maintain the uniformity that the new print functions introduce, we would need to provide the same interface that print() provides. Say, something like this should work. printf(format_string, blah, blah, file=stderr) I haven't looked into all the options of Python 3.0's format function, but if there is a conflict, in the key-word arguments with that of the print function, it could get tricky. Without a printf(), we can still write, something that looks very similar: print(format_string.format(blah, blah), file=stderr) Without printf, we need to type ".format(" and its matching ")"; 9 more characters. The opinion on whether the savings is worth enough to add another built-in is bound to differ from developer to developer. I think, we still have a few months more to wait and see. :-) Ideally, to maintain the uniformity that the new print functions introduce, we would need to provide the same interface that print() provides.

Say, something like this should work.

printf(format_string, blah, blah, file=stderr)

I haven’t looked into all the options of Python 3.0’s format function, but if there is a conflict, in the key-word arguments with that of the print function, it could get tricky.

Without a printf(), we can still write, something that looks very similar:
print(format_string.format(blah, blah), file=stderr)

Without printf, we need to type “.format(” and its matching “)”; 9 more characters.

The opinion on whether the savings is worth enough to add another built-in is bound to differ from developer to developer. I think, we still have a few months more to wait and see. :-)

]]>