[Python-3000] print() parameters in py3k

[Guido van Rossum]

On 11/20/06, Barry Warsaw <barry at python.org> wrote:
> >> Another thought: what if 'print' weren't a function but a callable
> >> object. exposed in builtins.  I'm thinking something roughly parallel
> >> to stdout, stderr, stdin, or maybe better cout, cerr, cin.
> >
> > I'm not sure I follow the difference. It was quite clear from earlier
> > discussions that we *don't* want print to be a bound method of a
> > hypothetical print method on sys.stdout; that's much less flexible,
> > and makes it much more work to implement a file-like type. print()
> > should dynamically look up sys.stdout each time it is called (and
> > exactly once per call).
> >
> > (BTW I'm not sure why you like cin/cout/cerr better than stdin/
> > stdout/stderr?)
>
> I was trying to make an analogy (probably poorly so) that 'print'
> would be bound to an instance as opposed to a function (current
> proposal) or structure-like thingie without methods as in std*.

Sorry, I still don't understand your proposal.

> >> The default 'print' object then would be a "print-to-sys.stdout-with-
> >> \n", but you would then be able to do something like:
> >>
> >> stderr = print.clone(stream=sys.stderr)
> >> stderr('here go all my error messages')
> >>
> >> or
> >>
> >> smtpout = print.clone(stream=mysock, end='\r\n')
> >> smtpout('$code $msg', code=250, msg='Okay')
> >
> > I'd like to firmly resist adding more mechanism for somethign that can
> > be addressed so simply by a tiny wrapper function:
> >
> > def smtpout(*args):
> >  print(*args, file=mysock, end="\r\n")
>
> What I was trying to address was the namespace collisions you'd get
> between printf-style keyword arguments and 'special' arguments that
> the print function would accept.  The thing is that if we were to add
> both a print and a printf, you'd like for their interfaces to be as
> similar as possible except that the latter takes a format string as
> its first argument.  Clearly 'special' arguments like 'file' and
> 'end' will prohibit their use as keyword arguments for printf, and I
> don't like that (this isn't anything new -- the problem crops up
> occasionally in other places, see the email package API).
>
> One way out would be to use special argument names, e.g. prepending
> and or appending some number of underscores.  This doesn't eliminate
> the problem, but it reduces its likelihood.  Another approach would
> for 'print' to be an object with attributes that would change
> behavior, such as the stream to write to or line-ending characters.
> A possible third approach might be some special singleton objects
> that, when seen positionally would modify the state of the underlying
> print object.  Of the three (maybe fourth: "sorry you can't use 'end'
> or 'file'"), it seems preferable to use a callable print object.

I still don't quite see how making print a callable object solves that
issue. But personally would be totally happy with "You can't use
'file' as a variable name in your format". ('end' and 'sep' should not
be supported by printf(), these should just be made part of the format
string.)

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)