PEP 259: Revise to remove context-driven magic from print

Carel Fellinger cfelling at iae.nl
Fri Jun 15 18:22:17 EDT 2001


Alex Martelli <aleaxit at yahoo.com> wrote:
>     ...
>> > No, __print__ would rather underlie the print statement just like
>> > __import__ underlies the import (and from) statements.  But I guess
>> > I gotta write a PEP about it...

please do, and...

> __builtin__.__print__ would be allowed to be any callable with a
> compatible interface to a 'bundled' __print__.  The latter would
> encode the current magic features of the print statements as kw
> arguments with optional values:
>     file=sys.stdout    set by the >>fileobject hack to file=fileobject
>     nl=1               set by a trailing-comma to nl=0

consider making this newline=1, as it's probably infrequent use will
make it hard to get to remember the shorthand.  (I myself, I've always
to think again seeing nl to map it to newline and not to Nederland, if
I'm the only one, don't bother)

>                        settable to nl=-1 to get the nl-stripping
>                          behavior that Guido wanted (no syntax for
>                          that in the print statement)
> (still to be designed: what if anything to do about .softspace play &c;
> whether to supply a few more kw's, without syntax for them in the print
> statement, just to ease customization & direct use -- I guess not, but...).

consider enhancing the print statement to resemble __print__ calls.
I think someone else already proposed it, like in:

   >>> print "spam", newline=1; print  "and spam", softspace=0
   spamand spam


I'm not sure I like this, as it suggest that the place of the keyword
assignment matters.  People could expect things like:

   >>> print "spam", softspace=0, 'and spam"
   spamand spam

And I'm *not* advocating such extra print magic, I'd rather have it raise
"SyntaxError: non-keyword arg after keyword arg", and have softspace only
deal with the first space.  (maybe an extra kw-arg softspaces to overrule
the special treatment of , all together?)




-- 
groetjes, carel



More information about the Python-list mailing list