| Store | Cart

"print" as function not statement

From: David MacQuigg <d...@gain.com>
Tue, 09 Mar 2004 14:04:13 -0700
On Sun, 07 Mar 2004 16:57:29 -0800, Paul Prescod <paul at prescod.net>

>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

>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
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

Recent Messages in this Thread
Mark Kamikaze Hughes Mar 08, 2004 01:36 am
John Roth Mar 08, 2004 02:38 am
Leif K-Brooks Mar 08, 2004 07:32 am
Duncan Booth Mar 08, 2004 08:31 am
Leif K-Brooks Mar 08, 2004 10:36 am
A.M. Kuchling Mar 08, 2004 01:29 pm
Heather Coppersmith Mar 08, 2004 12:56 pm
David MacQuigg Mar 09, 2004 09:04 pm
Aahz Mar 10, 2004 10:43 am
Peter Otten Mar 10, 2004 12:52 pm
David MacQuigg Mar 10, 2004 03:32 pm
Messages in this thread