[Python-3000] print() parameters in py3k

[Josiah Carlson]

Barry Warsaw <barry at python.org> wrote:
> On Nov 20, 2006, at 9:58 AM, Giovanni Bajo wrote:
> > Uhm, but then, why not simply:
> >
> > println(x,y,z) -> append "\n"
> > print(x,y,z) -> no terminator
> > print(x,y,z,"\r\n") -> custom terminator

I don't like the idea of 2 builtins to print (-1).  It doesn't feel
right. Then again, I'm not particularly interested in a print function
either (-0).


> I'd like to at least see a discussion of a more printf() or logging  
> style for print function.  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))

How much print statement rewriting do you want to do?  Me, I'd like to
get away with as little as possible.  Adding parenthesis isn't that bad. 
Changing everything to use a printf-style would be 1) annoying, 2)
unnecessary, and 3) I hate printf.

Not to say that #3 is a sufficient reason for everyone else, but when I
sit down to write C, among the standard annoyances I wish I didn't have
to deal with is that printf _requires_ that damn format string.  I
understand it is a requirement due to underlying language limitations,
but Python has no such limitations, so let us not burdon Python with the
braindead nature of C's printf.

I would also mention that there would be no way to distinguish between
the two cases you specify above (within print()), unless we are going to
remove % formatting, which would be a mistake.


> There are lots of questions to answer, such as whether to use $- 
> strings and require keyword arguments.

Bad idea.  Unless we are changing all of string formatting to use $,
then changing the default string formatting of one of the likely most
used functions, is at best confusing, and certainly gratuitous breakage.
Then again, I never saw that using required parens and a specifier like
%(...)s was a burden...


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

We still wouldn't be able to get "cin << bar" without frame hacking, and
I would be content to never see "cout >> foo" or "cin << bar" ever again.
The 2.x "convenience syntax" of print >>foo, ... I think was a decent
feature, brought on by the desire to make print usable for non-stdout
streams.  cout/cerr/cin, almost by definition, are C++ hacks and/or
misfeatures, and adding them to Python seems to be silly to me;
regardless of the 5 (or fewer) C++ users who don't know how to use C's
printf, or who wouldn't be able to understand Python's print().

We've got raw_input() and print().  If users want alternate
functionality, they can write their own print function and even assign
it to __builtins__.print .


> 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 guess I don't really see either of these as significant improvements,
if any, to the guido-defined print function.


> Perhaps you could even hook in i18n by doing something like:
> 
> print = print.clone(translate=gettext.gettext)
> print('$who likes to eat $what', person, food)

Except that would need to be...

print('$who likes to eat $what', who=person, what=food)

This is the only feature that I raise my eyebrow and say, 'that would be
somewhat convenient', but with print as a function, users can _easily_
do that by themselves...

_print = print
def print_(line, **kwargs):
    _print(gettext.gettext(line), **kwargs)
__builtins__.print = print_

Heck, toss a couple fairly simple examples into the print()
documentation, the cookbook, and/or some module, and I think user desire
would be satisfied.

 - Josiah