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

[Alex Martelli]

"Remco Gerlich" <scarblac at pino.selwerd.nl> wrote in message
news:slrn9ijalb.697.scarblac at pino.selwerd.nl...
    ...
> > 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...
>
> I'm missing the point, I think. What would be useful about that function?

Exactly the same customizability/wrappability that __import__
supplies to the import statement.


> I suppose you could override it if you wanted to change print's behavior
> by assigning to __builtin__.__print__ or so, but then you have a global
> magic function!

Except for the peculiar wordchoice of "magic" (what's "magic" about it?),
yes: this would work exactly like __builtin__.__import__ does

> And if you override it locally, I don't see how print would
> use it. Overriding the way print works globally sounds like Perl to me.

Why is this any different from "overriding the way import works
globally", which sounds like Python to me?-)

> __import__ is useful if you want to do call it with a string, or do
> something with it other than assign it to a name in the local namespace.
But
> I don't see any equivalent things with __print__.

Yes, __import__ has secondary uses, but that's not its main reason
for being.

The holy docs put it well: "It mainly exists so that you can replace
it with another function that has a compatible interface, in order
to change the semantics of the import statement".  That's in 2.3 in
the Library Reference -- hardly an obscure corner of the docs:-).

Are you arguing against the Library Reference?-)

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

Of course HAVING this behavior as a bundled function has its uses,
just like for __import__ albeit different ones.  For example, use
    __print__(*lotsofitems)
instead of
    for item in lotsofitems:
        print item,
    print
when you have to print each item in a sequence of items.


Alex