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

Alex Martelli aleaxit at yahoo.com
Tue Jun 12 09:08:23 EDT 2001

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

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

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.

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

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.

> 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:-).

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

So why don't I write my output() function and just use
it?  That's not enough, because I use a lot of code I
did not write -- and that code "coming from outside" is
not going to use MY private conventions.  If it uses
(overtly or indirectly) a built-in function, I get a
chance to wrap that and make the code-from-outside of
some use for my purposes.  Otherwise, I'm SOL.

See why one should use isinstance(x,y) even when y is
a type-object, for example?  Why not just type(x)==y?
*Because* the latter idiom is not sensibly tweakable
non-invasively -- I can hardly wrap/override type()
without knowing what's going to be done with its
result.  I _can_ at least wrap isinstance, and thus
defeat some of the typechecks that may be killing me
in external code I'm reusing...:-).  [Maybe not the
best of examples, because it's STILL a bother, but,
until and unless we get PEP 246, it's gonna be hard
to uproot typechecks altogether:-)].


More information about the Python-list mailing list