[Python-3000] print() parameters in py3k
barry at python.org
Mon Nov 20 20:03:47 CET 2006
-----BEGIN PGP SIGNED MESSAGE-----
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()
>> 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/
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')
>> 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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)
-----END PGP SIGNATURE-----
More information about the Python-3000