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