On 9/3/05, Bill Janssen <[EMAIL PROTECTED]> wrote: > So here's the summary of the arguments against: two style points > (trailing comma and >>stream) (from the man who approved the current > decorator syntax!), and it's hard to extend. (By the way, I agree that > the ">>" syntax is ugly, and IMO a bad idea in general. Shame the "@" > wasn't used instead. :-) > > Seems pretty weak to me. Are there other args against?
Sure. I made the mistake of thinking that everybody knew them. But let me first summarize the arguments I've heard for keeping print as a statement: 1. It's always been there 2. We don't want to type parentheses 3. We use it a lot 4. We don't want to change our code I agree that those are strong arguments, so please hear me out. There is a theoretical argument: print is the only application-level functionality that has a statement dedicated to it. Within Python's world, syntax is generally used as a last resort, when something *can't* be done without help from the compiler. Print doesn't qualify for such an exception (quite the opposite actually). But more important to me are my own experiences exploring the boundaries of print. - I quite often come to a point in the evolution of a program where I need to change all print statements into logging calls, or calls into some other I/O or UI library. If print were a function, this would be a straightforward string replacement; as it is, finding where to add the parentheses is often a pain (the end isn't always on the same line as the start). It's even worse if there are already ">>stream" options present. Trailing commas also make this more complicated than it needs to be. - Having special syntax puts up a much larger barrier for evolution of a feature. For examle, adding printf (or changing print to printf) is a much bigger deal now that print is a statement than if it had been a built-in function: trial implementations are much more work, there are only a few people who know how to modify Python's bytecode compiler, etc. (Having printf() be a function and print remain a statement is of course a possibility, but only adds more confusion and makes printf() a second-class citizen, thereby proving my point.) - There is a distinct non-linearity in print's ease of use once you decide that you don't want to have spaces between items; you either have to switch to using sys.stdout.write(), or you have to collect all items in a string. This is not a simple transformation, consider what it takes to get rid of the spaces before the commas in this simple example: print "x =", x, ", y =", y, ", z =", z If it was a built-in function, having a built-in companion function that did a similar thing without inserting spaces and adding a newline would be the logical thing to do (or adding keyword parameters to control that behavior; but I prefer a second function); but with only print as it currently stands, you'd have to switch to something like print "x = " + str(x) + ", y = " + str(x) + ", z = " + str(z) or print "x = %s, y = %s, z = %s" % (x, y, z) neither of which is very attractive. (And don't tell me that the spaces are no big deal -- they aren't in *this* example, but they are in other situations.) - If it were a function, it would be much easier to replace it within one module (just def print(*args):...) or even throughout a program (e.g. by putting a different function in __builtin__.print). As it is, you can do this by writing a class with a write( ) method and assigning that to sys.stdout -- that's not bad, but definitely a much larger conceptual leap, and it works at a different level than print. Summarizing, my main problems with print as a statement are the transformations -- when print doesn't cut it, you have to switch to something entirely different. If it were a function the switch would feel much smoother. I find that important: things that are conceptually related should be syntactically related (within the realm of common sense, as always). -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com