PEP 0214 - extended print statement

[Ralph Corderoy]

Hi Chris,

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

I have to agree.  I've written practically no Python but have been
lurking on the newgroup for a while and have read the User and
Reference manual that accompanies Python.  My background centres around
Unix/C, with Perl from around the time of Perl 4.

The use of `>>' for I/O redirection is very familiar from the Bourne
shell but there it is accompanied by all the other operators that have
similar appearance and function, e.g. >, <, and n>&m.  Overloading it
in Python when immediately following the print keyword seems more what
Perl would do than Python.

>From a performance viewpoint I'm relunctant to use a function to
implement the behaviour.

awk has a string concatenation operation, but no operator;  simply
placing two strings adjacent concatenates them.  Perl does something
similar with its `print name, age' v. `print STDERR name, age';  STDERR
is recognised as being something that can be printed to.  Attempting
the same in Python prints a representation of the file.

    >>> print sys.stdout
    <open file '<stdout>', mode 'w' at 8093db0>

Rather than an operator, how about something textual?

    print in sys.stderr name, age

`in' is already a reserved word, IIRC;  `to' would be better and could
be made only special when immediately following `print' but that would
muddle the waters a little.  The lack of a comma after the file seems
important since it re-inforces to the scanning eye that the file isn't
an item being printed.

> 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

I'd favour the file up front;  that's typically more important on a
first read than exactly what is being printed.


Ralph.