"print" as function not statement

[David MacQuigg]

On Sun, 07 Mar 2004 16:57:29 -0800, Paul Prescod <paul at prescod.net>
wrote:

>This is just a trial balloon. It isn't even in proper PEP format yet. 
>Don't take it too personally!
>
>Pre-pep for a show() built-in function.
>
>	This pre-PEP describes a replacement for the Python print
>	statement.  Obviously the replacement of such a popular
>	statement will take time and cause dislocation. It must
>	therefore be done very gradually and carefully.  Nevertheless,
>	the print statement stands out in Python because of its
>	quirky syntax and semantics. This PEP proposes to migrate
>	the print statement towards standardized function syntax.

At this point, my initial reaction was "no way".  After reading the
rest of the proposal, I say "yes".  Your arguments are very
convincing.

>Problems with "print"
>
>	New users are constantly asking how to print elements without
>	trailing whitespace.

And the answer is easy, but not obvious to a beginner, and also
something beginners tend to resist, as if having once been spoiled on
a print statement without parens, it is now too much work to type 
printX( ... )

This to me, is the most powerful argument.

>	The use of a trailing comma to disable newline has no clear
>	relation to any other syntax elsewhere in Python.
>
>	The cheveron syntax is similarly unique.

Both good points.

>	"print" is the one of only two statement-generating keywords
>	that is not a flow-control or scope-control operator.

Don't care.  I have never thought about the underlying 'nature' of
these statements, and I wouldn't fault a language for this.

>	Because print is a statement, it cannot be used in contexts
>	like list comprehensions and lambda functions.

I've hit this snag.

>	The word "print" is very common in English usage and would be
>	very useful for method and function names. It is  a (very)
>	long-term goal of this PEP to free it up for this purpose.

Perhaps we could retain the deprecated form in a module to be accessed
with 
from __the_past__ import print      :>)

[ snip ]

>Proposed solution: "show"
>
>	I propose a new built-in function called "show". It can take an
>	arbitrary number of positional arguments and three optional
>	keyword arguments:
>	
>		* separator - string to use to separate the string
>		displays of the objects that are written. Defaults
>		to a single space.
>
>		* trailer - string that follows the string displays
>		of the objects that are written. Defaults to a
>		single newline.
>
>		* to - a file object to write the strings to. Defaults
>		to sys.stdout.
>
>	Some examples:
>
>		show(5)
>
>		show(5, to = sys.stderr)
>
>		show(5, 6, separator = ",")
>
>		show(5, 6, trailer = "\n\n")
>
>		show("Five", 5, "Six", 6)
>
>		show(show)

This is clearly the right way to re-write an old function, extending
the options, but preserving the old behavior as a default.  I would
like to do the same with some of the convenience functions in the
os.path module (exists, isfile, isdir).  Convenience is fine, but
don't hide the primitives.

>Possible Extensions
>
>	Debug-useful return value
>
[ snip ]
>		x = show(j[x]).y(a[x])

This would be very handy.

Go for it !!

-- Dave