PEP 0214 - extended print statement

[thanos vassilakis]

Alex Martelli wrote:

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

Python works. C++ doesn't, hence Java, python, etc. Lets keep it that way.