[Python-3000] print() parameters in py3k

[Brett Cannon]

On 11/20/06, Barry Warsaw <barry at python.org> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Nov 20, 2006, at 1:21 PM, Guido van Rossum wrote:
>
> > On 11/20/06, Barry Warsaw <barry at python.org> wrote:
> >> I'd like to at least see a discussion of a more printf() or logging
> >> style for print function.
> >
> > Agreed, as long as it isn't presented as an alternative to the more
> > basic print() function. We don't want to force students making their
> > first forays into programming to have to learn format strings. Having
> > printf() for more advanced use together with print() as defined in PEP
> > 3105 makes sense to me.
>
> That seems reasonable to me too (separate print() and printf()
> thingies).
>
> >> Specifically, I wonder if it wouldn't be
> >> useful to require a format string with positional and keyword
> >> arguments being used for automatic interpolation.  E.g.
> >>
> >> print('%s: %s', field, value)
> >>
> >> instead of
> >>
> >> print('%s: %s' % (field, value))
> >
> > Before going too far down this route, first read PEP 3101, which
> > proposes a different way out of the issues around the % operator. (Not
> > saying we couldn't adopt PEP 3101 *and* a printf() function.
>
> Thanks for the pointer.  I agree that if we adopt a companion printf
> () function it should definitely require (only) PEP 3101 format strings.
>
> >> 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*.
>
> >> 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).


Why do they need to be similar?  print() is just a really simple, quick
output function.  printf() seems to be proposed for advanced formatting
needs for sending to stdout.  As Guido said, the newline should be explicit
in printf(), so that already begins to deviate from print().  And 'sep'
would be useless.  So all that leaves is 'file', and that is just
convenience for passing a string to a 'write' method.  And for that I think
people can just learn not to use 'file' as a name of a variable.  Or we can
just lose that as well and have printf() be nothing more than a convenience
function that avoids having to specify the method name and sending it to
print with the desired arguments.

Then again, this to me seems to make printf() not that grand to lead to its
own built-in.  But I have been fine with the way things have been so far
anyway with having a separate line that stores some string I created before
calling 'print'.  If you don't have any keyword arguments then printf() is
just::

  def printf(format_string, *args, **kwargs):
      output = format_string.format(*args, **kwargs)
      print(output, end='')


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.


I don't see this being a big problem if the only argument that is common is
'file'.

  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.


Yuck.  Why would you want to suddenly set global semantics in a built-in
instead of a module?  That's a total shift in how Python does things at a
global level.  Plus I don't want to have to worry about setting 'sep' or
'end' for every function that uses print() just because some other function
decided that it didn't like single spaces but wanted to use tabs for a
separator.

A possible third approach might be some special singleton objects
> that, when seen positionally would modify the state of the underlying
> print object.


Yuck again. This seems to be getting rather specific just for printing when
we have already lived without all of this functionality for so long with
minor issue.

  Of the three (maybe fourth: "sorry you can't use 'end'
> or 'file'"),


I like this option.  =)

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20061120/781abb99/attachment.htm