gratuitous new features in 2.0

[Martijn Faassen]

Guido van Rossum <guido at beopen.com> wrote:
> [Robin Becker]
>> I would prefer a writeln(stderr,item,.....), but then I can already do
>> that myself.

> If you state it this way, a method would be more appropriate; we could
> have added a method writeln(item, ...) to standard file objects.

Sure, a method and a simple builtin function referring to the method on
sys.stdout, like:

println = sys.stdout.println

> First of all, this is lacking a feature of the print statement: the
> trailing comma to print which suppresses the final newline.  Note that
> 'print a,' still isn't equivalent to 'sys.stdout.write(a)' -- print
> inserts a space between items, and takes arbitrary objects as
> arguments; write() doesn't insert a space and requires a single
> string.

So add something like print_comma (*not* the suggested word) as a method.

> When you are considering an extension for the print statement, it's
> not right to add a function or method that adds a new feature in one
> dimension (where the output goes) but takes away in another dimension
> (spaces between items, and the choice of trailing newline or not).  We
> could add a whole slew of methods or functions to deal with the
> various cases but that seems to add more confusion than necessary,

A whole slew means two new methods, and possibly two new builtins that
refer to those methods in stdout, right? Somewhat like this:

def pprint_comma(self, *args):
    self.write(string.join(map(str, args)))
    
def pprint(self, *args):
    self.write(string.join(map(str, args)) + "\n") 

Provide a mixin for folks who want these with their own file-like objects.

> and
> would only make sense if we were to deprecate the print statement
> altogether.

That was my initial conclusion too, but why, really? I mean, we are now
faced with two realistic alternatives:

  * add the >> stuff to 'print'

  * keep 'print' as it is, and add a few methods to the standard library,
    and possibly some built-ins.

The latter option does not mean we need to deprecate 'print'; it's just still
in my opinion a much cleaner solution than the >> stuff. You can say
'the print statement is just syntactic sugar for the sys.stdout.pprint()
function and the sys.stdout.pprint_comma() function', right?

> I feel that this debate is really about whether print should have been
> a function or method rather than a statement.  If you are in the
> function camp, of course adding special syntax to the existing print
> statement is not something you like.  I suspect the objection to the
> new syntax comes mostly from people who already think that the print
> statement was a bad idea.  Am I right?

I never thought the 'print' statement was a bad idea, myself. I do 
think the >> addition to print isn't a very good idea. And it makes me
realise *now* that 'print' ought to have been a function all along. :)
Before this proposal, I didn't think so.
 
> About 10 years ago I debated with myself whether to make the most
> basic from of output a function or a statement; basically I was trying
> to decide between "print(item, ...)" and "print item, ...".  I chose
> to make it a statement because printing needs to be taught very early
> on, and is very important in the programs that beginners write.

And beginners cannot learn to add a ( and a ), right? :)
Keeping the syntax simple for beginners, sure, but beginners will
definitely run into ( and ) very very quickly in any case. In my 
personal attempt at teaching Python, they see ( and ) before they
see 'print', as interactive mode already does do print, and I was teaching
them about expressions, int() and str() and the like.

[snip]

> Anyway, I'm not ready to deprecate the print statement, and over the
> years we've had many requests for an option to specify the file (but
> that's all in the PEP).

Not being ready to deprecate the print statement does not mean you're not
ready to add an alternative to 'print'. Presumably the >> stuff is 
intended for advanced users, not for beginners. Presumably more advanced
users know how to use a method already (it's easy..no debates on whether
a comma should be there or whether >> should be usedor something else).
So what's the problem?

Finally, I don't think the '>>' in print will be a disaster, so I
won't worry too much about it. I don't consider a domino scenario
likely; I doubt print will afterwards grow even more options and
knobs.

This addition does seem to bring the problems with print as a statement
to the fore, and I'll remember that for when I ever
design my own language. Note to self: make print a built-in function
(or method), not a statement. :)

Regards,

Martijn
-- 
History of the 20th Century: WW1, WW2, WW3?
No, WWW -- Could we be going in the right direction?