On 9/3/05, Guido van Rossum <[EMAIL PROTECTED]> wrote: > Wow. > > With so many people expressing a gut response and not saying what in > the proposal they don't like, it's hard to even start a response.
Fair point. > Is it... > > - Going from statement to function? I thought this was a major issue, but Nick Coghlan's output() function has persuaded me otherwise. Now, I'd say I was more concerned about going from *one* statement to *six* functions (the number you explicitly referred to in your posting - 3 methods and 3 builtins - but I'd be willing to concede that the exact number needed is vague, not least because the write method already exists...) > - Losing the automatically inserted space? This was important to me. > - Having to write more to get a newline appended? Not so much "more" as "ugly" - the function name writeln reminds me of Pascal (not a good thing!), and an explicit "\n" obscures the main intent of the code. > - Losing the name 'print'? Not a big deal, but it seems gratuitous. > Some responses seemed to have missed (or perhaps for stronger > rhetorical effect intentionally neglected) that I was proposing > builtins in addition to the stream methods, The opposite - to me, that just increases the number of proposed functions, which is one of my objections :-) > I'd like to be flexible on all points *except* the syntax -- I really > want to get rid of print as a *statement*. OK, how about a *single* builtin, named "print", which works something like Nick Coghlan's proposal (I'm happy to fiddle with the details, but the basic principle is that it can do all the variations the print statement can currently do - plus extra, in the case of Nick's code). It should rely solely on a stream having a "write" method (so there's no change to the "file-like object" interface, and existing objects don't need to be changed to support the new proposal). If you really want a stream.print method, I can cope, as long as it's clear that it's an *optional* part of the file-like interface - after all, it's a convenience method only. A mixin providing it might work, but I've no idea how you'd do a mixin which file-like objects implemented in C could use... A name other than "print" for the new builtin has the benefit that it could be introduced now, with Python 3.0 merely removing the print statement in its favour. But there isn't really a name I like as much as "print", and at least you *know* that no-one is using variable names that would hide a print builtin :-) > Consider this: if Python *didn't* have a print statement, but it had a > built-in function with the same functionality (including, say, keyword > parameters to suppress the trailing newline or the space between > items); would anyone support a proposal to make it a statement > instead? No - and if that builtin was what you had proposed, you may not have got such a negative reaction :-) Paul. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
