[Python-Dev] Replacement for print in Python 3.0 (original) (raw)

Brett Cannon bcannon at gmail.com
Tue Sep 6 06:01:20 CEST 2005

On 9/5/05, Barry Warsaw <barry at python.org> wrote:

On Mon, 2005-09-05 at 20:52, Guido van Rossum wrote:

> We could decide not to provide (b) directly, since it is easily > reduced to (c) using an appropriate format string ("%s" times the > number of arguments). But I expect that use case (b) is pretty > important, and not everyone likes having to use format strings. This > could be reduced to a special case of the Swiss Army Knife (...Not) > rule. I'm not sure. I do agree with your design principles (though I might call it "Sometime's a Spoon's Just a Spoon" ;) but thinking about my own uses of print, I think we could easily get away with just (a) and (c). I think someone else felt the same way in an earlier response to my strawman, pointing out that the inline Separator instances wasn't really any more usable than just degenerating to the format string version. There's no doubt that the format string approach gives you direct control over every character. Eliminating the newline argument from print() would reduce the number of reserved keyword arguments in my strawman by half. Maybe we could even rename 'to' to 'to' (!) to eliminate the other namespace wart. Is this really too horrible: print('$user forgot to frobnicate the $file!\n', user=username, file=file.name, to=sys.stderr)

If I something stupid, I apologize; I have been swamped with orientation stuff while this entire discussion has been going on and so I am sure I have missed some of the finer details.

I like the way the above works, but print(username, "forgot to frobicate the", file.name) just seems nicer for simple output. I do agree that there is a need for simple and formatted versions of print and that controlled output of numbers is important. And I also like the $ formatting so I wished there was a way to take what Barry did above but be able to do formatting, like ${num:0.6f} or something and have that be the formatting version and just have the default be a call on str() for the substitution.

> BTW we could use "from future import printing" to disable the > recognition of 'print' as a keyword in a particular module -- this > would provide adequate future-proofing.

+1

+1 from me as well.

-Brett

More information about the Python-Dev mailing list