[Python-Dev] PEP 259: Omit printing newline after newline

[Bengt Richter]

On Tue, 12 Jun 2001 11:29:50 +0200, "Alex Martelli"
<aleaxit at yahoo.com> wrote:
[...interesting stuff...]
>
>So, summarizing: in Python, keyword statements either
>affect the namespace using them, or affect the control
>flow that uses them.
>
>All, that is... except ONE.
>
>That one is: print.  A keyword statement that neither
>affects the namespace, nor control flow.  An anomaly,
>therefore, that sticks out like a sore thumb.  Surely
>not such a huge one that it's worth breaking 99% of
>existing scripts to remove it:-).  *However* -- why
>keep overloading it with magic and extra "convenience"
>features...?  Glyph may be right in paradoxically
>claiming that just such tweaking will eventually show
>everyone that print is just best not used:-).
>
>To HELP migration to a function for what is now done
>with print, I think such a built-in function should be
>added contextually to this latest 'print' change.  Yes,
>yes, it IS un-Pythonic to provide several ways to do
>the same task, but, here, I think, we need to patch
>over the non-Pythonic existence of print itself:-).
>
>I believe the new print-like built-in function should
>ideally be named print, but we can't do it, because
>keywords are reserved.  Sigh.  Among the alternatives,
Is it not possible to back out a keyword if it doesn't
break a lot of code? If it were possible, wouldn't
reducing the keyword count be a Good Thing?

What if print were definable as a peculiar unary operator
whose precedence and associativity led to its being
called with a tuple constructed from the typical print
args? If this operator was defined as a builtin function,
you could hook in whatever you liked.

If there were a general capability to define named
operators with rules for precedence and associativity
etc to gather arguments, you could do print as just
one example of a general capability.

>we have: write (misleading as it recalls the write
>method of file-objects), output (makes for a nice
>pair with input, which, however, has its own nasty
>problems:-), emit, say (a la Rexx), echo (a la sh),
>and many others, including non-words that decorate
>these basic words (doprint, etc).
>
>Whatever name is used (assume 'output' for definiteness,
>without loss of generality), I think the print-like
>function should accept arbitrary unnamed arguments
>(to be treated just like the items now passed to
>print) optionally followed by named arguments to
>supply the same tweaks that now print supplies (and
>maybe a few more) -- names are doubtful, but...:
>    file=sys.stdout   the output file-object to use
>    newl=1            1 emit a newline at the end
>                        UNLESS the last item printed
>                        is a string ending in \n
>                        (like print will now work)
>                      0 no newline at the end (like
>                        print with a trailing comma)
>                      2 force newline at the end in
>                        any case (like print today)
>    (others?)
Alternatively (and possibly more concisely) borrow an idea
from C++ "Standard I/O Manipulators" and pass references to
standard 'manipulator' objects?

[...]
>Having output as a built-in function would encourage
>using it in lieu of the print statement, which, in
>turn, would allow the usual kind of tricks that are
>available for built-ins but not for statements, such
>as wrapping/overriding (you can do that for print with
>a user-defined file-like object, to some extent, but
>not fully -- the file-like object cannot know where
>a given print statement begins or ends, it can only
>intercept specific write and softspace accesses).
>
I like wrappability. As for PEP 259, please count one
newbie vote against. In general, I'd prefer that a language
provide a clean way to create a solution to a problem,
rather than having a particular solution built in.
I like orthogonality too.