PEP 0214 - extended print statement

[Alex Martelli]

"Chris Ryland" <cpr at emsoftware.com> wrote in message
news:W_in5.364$Y2.3247 at news...
> Please forgive a relative Python newbie's whining (and forgive me if this
> has already been discussed in public), but I think the proposed extended
> print syntax is TERRIBLE.

As a not-too-long-ago newbie myself, I second your motion most heartily.


> (Viz., simplifying, print >> outfile, something .)
>
> This seems very un-Pythonic in that it's overloading the >> operator and
> giving it a completely unrelated meaning in this one, lonely context.

Hear, hear.  Python is not and should not be C++.


> Since the print statement is already quite special, why overload an
existing
> valid operator? Just add another (non-reserved, perhaps) keyword, along
the
> lines of
>
> print something to outfile
>
> Comments?

I disagree on this part.  The writeln function (if I recall the name
correctly),
that is also specified as a possible alternative in the same PEP, seems to
me
to be a much better solution.  Why add keywords, or munge existing ones?
Adding a builtin function is much less 'invasive', and does not change the
core language for little or no gain.


The print statement as it stands is excellent for newbies (I don't have to
teach them anything about functions yet -- they can see some output more
easily with it) and for quick and dirty output-to-stdout (e.g. to check the
value of some intermediate expression while developing).  I do not think
it can or should be stretched to do much more than this: for more refined
stuff, a function call seems a far better way to go.

Maybe it would be better if the function's name recalled the 'print' keyword
in the statement, rather than 'write' which is something else, but I don't
have a specific suggestion for that.  'print' itself is of course a reserved
word, and variations with mixedcase or underlines are not normally used
in builtin functions' names; 'printf' is ugly-ish; etc.  But I think the
naming
issue may be secondary.  The key one seems to me: avoid a change to the
core language when the same effect may be better obtained with functions.


Alex