[Python-3000] print() parameters in py3k

[Barry Warsaw]

-----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).

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.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iQCVAwUBRWH8GXEjvBPtnXfVAQL0BQP/SoF2ETUnUlept5pPwzzeAQdOJjcKuEjL
3saKhz0QAVfCktxTTFK4hZQGeYHKLTSWemr3A+zl82lc58rmSGr8OemXDLXy1J7l
PplFkp4iBrT8mLKSFL2c397IKg0M/hbfb3Iw2NqNBu8h2pA1d1bAozBR+nNClUGP
z6vCi1zfYvk=
=7G56
-----END PGP SIGNATURE-----