Re: functions versus statements (from WIKI)

Mark Hahn wrote:

> I'm in the middle of writing the tutorial and I'm dealing with the
> embarrasment of explaining the double prints in the console. Soon I will be
> trying to explain why print is now a function and why it returns what it
> prints as a return value. Frankly I have no idea why it returns anything and
> I really don't have any idea why it is a function. I know Guido wants Python
> print to change to a function and this is the current "in thing" to do. I
> have some vague idea one may want to print in a list comprehension but I
> doubt I'd ever do that.

http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&safe=off&threadm=mailman.107.1078707454.19534.python-list%40python.org&rnum=1&prev=/groups%3Fq%3Dprint%2Bfunction%2B%2Bstatement%26hl%3Den%26lr%3D%26ie%3DUTF-8%26safe%3Doff%26selm%3Dmailman.107.1078707454.19534.python-list%2540python.org%26rnum%3D1

Print should be as function for the same reason printf is a function in 
C. It has nothing to do with flow-control so why should it be a 
statement? Also as a keyword it removes the possibility for any object 
to have a "print" method (unless Prothon has contextual keywords: Python 
doesn't).

Having the function return its value is a convenience for debugging. If 
it will simplify life (it seems it will) then I propose a separate 
function called "debug" that returns its result. Here's the situation.

x = f( 5 + 32 * Z(abc[23]))

Now you want to add something that will help you see what Z(abc[23]) is 
while you are debugging. Usually you have to refactor and you could 
introduce an error doing so. With debug you just do this:

print "XXX"
x = f( 5 + 32 * debug(Z(abc[23])))

> Note: Since this was written I removed the return values from the print
> function to fix the double prints.  This is not necessarily a long-term
> solution.

The simplest thing is probably just to have "print" defined as

def print(*args, **kwargs):
     debug(*args, **kwargs)
     return None

  Paul Prescod