"print" as function not statement

[Paul Prescod]

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.

Problems with "print"

	New users are constantly asking how to print elements without
	trailing whitespace.

	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.

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

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

	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.

	"print" is one of the first thing a Python newbie learns but
	learning it teaches very little about the rest of the language.
	All of the idiosyncratic syntax you learn will never be seen
	again elsewhere in the language and 99.9% of non-control flow
	operations are performed with functions, not statements.

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)

Possible Extensions

	Debug-useful return value

		As a convenience, if the show function is passed a
		single object to show, it returns that object. If
		it is passed more then one, it returns them as a
		tuple. This can be very convenient in debugging
		contexts. Consider if you are trying to debug the
		statement:

		x = j[x].y(a[x])

		A traditional way to debug sub-parts of the expression
		is like this:

		temp1 = j[x]
		x = temp.y(a[x])

		But this code contortion can add bugs. A less
		invasive change is:

		x = show(j[x]).y(a[x])

		This involves no logic change.

	Softspace

		The current "print" statement has some sophisticated
		handling of newlines and leading separators. The
		Python community may feel that it is worthwhile to
		port these concepts to the show function. The current
		PEP author does not.

	Method syntax

		Various function objects could add a convenience method
		also called "show" with the semantics of:

		def show(self, *args, **kwargs):
			show(to=self, *args, **kwargs)

		This would allow constructs like:

		sys.stdout.show(5, trailer="**\n")

	Different name

		Of course the name "show" is not written in stone.

		"print" is not available because we are changing
		its semantics.

		"write" is not advisable because fileobject.write() 				means 
something related but different.
		
		"prn" is over-cryptic.