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

[Chris Gonnerman]

----- Original Message -----
From: "Alex Martelli" <aleaxit at yahoo.com>
Newsgroups: comp.lang.python
To: <python-list at python.org>
Sent: Tuesday, June 12, 2001 8:08 AM
Subject: Re: [Python-Dev] PEP 259: Omit printing newline after newline


> "Chris Gonnerman" <chris.gonnerman at newcenturycomputers.net> wrote in
message
> news:mailman.992346739.24842.python-list at python.org...
> > From: "Roman Suzi" <rnd at onego.ru>
> > > No, no! Do not take print away! It help to migrate from Basic! ;-)
> >
> > This is the best single reason I can see OTHER than not breaking
existing
> > scripts.
> > Not just BASIC, but Perl, and SO MANY other languages have a print
> > statement.
>
> Ah, yes.  Perl compatibility is definitely a must, isn't it...?
>
> Not VB, because that has no "print statement" -- is has a
> "print #" statement, and the #filenumber part is mandatory;
> it writes to a disk file.
>
> Not C, which uses a printf *FUNCTION*.  Not C++ (which uses
> the << operator).  Not Java.  If compatibility or migration
> help from other languages is "the best reason" (apart from
> not breaking working code) for print's existence as a
> statement, then it seems the reasons in print's favour
> are even weaker than I thought.

Trust Alex to beat me over the head with the facts... :^)

Note that tcl has a puts statement which fundamentally works
like Python's print... just with a different name.

Languages with a print statement fundamentally similar to
Python/Perl:

    BASIC
    bc
    ksh

Languages with a very similar statement with a different name:

    *nix sh/csh     echo
    REXX            say

> Meanwhile, there ARE people out there (beginners, but not
> idiots:-) who might like
>     print
> to PRINT -- yet when they use it, their printer doesn't do
> anything... stuff gets displayed on-screen, NOT printed.

Point.

> Those guys and gals have never seen a 'printing terminal',
> and this idiomatic usage of a verb which DOES have an
> obvious, different, and perfectly current meaning in
> 'computerese' is hardly a good idea in a CP4E setting.

Point.

> > IMHO Alex's output() function is not really necessary.  If you hate
print,
> > use fileobj.write(), and leave us print-users alone.
>
> Several built-in functions "are not really necessary".
> Why have dir(x) when vars(x).keys() is equivalent, for
> example?  Speed, convenience, solidity.
>
> If an output function were defined, it could play the
> same role wrt the print statement as __import__ plays
> wrt the import and from statements.  The statement
> would remain (of course: breaking a vast majority of
> all scripts would be silly), *AND* it would be
> defined and documented to internally invoke the function.

Well why didn't you say so?  THAT sounds like a FINE idea!

> So the programmer gets a chance to "override" the
> function and get a global effect even when another
> module used the statement instead.  Perhaps, in this
> spirit, the function should be named __print__, then.

I agree here... __print__ is to print as __import__ is to import.

> > Aesthetics alone are not a good enough reason for such a fundamental and
> > painful change.
>
> Absolute agreement here!  Aesthetics are shifty, and a
> frail reed indeed.  Hardly good reason for ANY change
> (for doing things right in the first place, maybe, but
> not even Guido can get 100% right -- yet he has a far
> better track record in taking right design decisions
> than anybody else I've ever met or heard about:-).

Glad I didn't totally bomb...

> But the statement/function distinction is NOT chiefly
> about "aesthetics".  It IS chiefly about functionality.
>
> print has no real reason to exist as a statement, but,
> OK, it get grandfathered in (note that this would argue
> for leaving the default to respect-all-newlines, rather
> than Guido's new idea of removing SOME newlines).

EXACTLY.  As I so often ask customers, "what does this buy you?"

> Having
> print as a statement gives no real advantage, but it does
> give some disadvantages _unless_ the underlying functionality
> can be tweaked.  You can do MANY tweaks by using a wrapped
> file-like-object as stdout, but NOT all -- the file-object
> is not "told" about how many print statements are being
> processed, so it can't do such tweaks as the one that is
> now being proposed by Guido.  A __print__ underlying
> function would solve that.  Having a friendly name such
> as output is nice but secondary.

I'll happily agree to an "undercover" change to print which does
not break all my existing CGI scripts.  Explicit is better than
implicit, right?  So given that I read the manual and know that
print adds a newline, and I add a newline, any errors are my own
fault.  Have it start taking them out and BOOM.

Changing print to call __builtins__.__print__ (and allowing that
function to be overridden) would give the changemongers something
to use and leave us old-fashioned types safe.