Python Oddity - print a reserved name

[Bengt Richter]

On Thu, 16 Sep 2004 03:39:05 +0200, "Diez B. Roggisch" <deetsNOSPAM at web.de> wrote:

>> Why? If a print statement were just syntactic sugar for print((outfile,),
>> ... rest, of, line) (normally calling a builtin) then, giving your example
>> args,
>> 
>>     def print(*args):
>>         import sys
>>         sys.stdout.write( repr(args)+'\n')
>> 
>>     print print, 1, 'two', 3
>> 
>> would output (faked ;-)
>> 
>> '((), <function print at 0x008FDE70> 1, "two", 3)'
>
>
>How should that happen? As
>
>print
>
>produces a newline, one should expect that
>
>print print
>
>gets translated to 
>
>print(outfile, print(outfile,))
>
No, the second print in print print is just a name.
The translation is
    print((), print)
where after this translation both prints are ordinary names, and the print
statement per se is effectively forgotten as far as compilation is concerned.

That's why it finds <function print at 0x008FDE70> from the def print if there is one,
or otherwise the builtin print _function_. Either way, it's a function found in the
ordinary way by the name print.

The point is, a print statement is recognized _syntactically_ by 'print' being the
first name in the statement, but for the rest of the statement 'print' is an ordinary name.
Thus 
    print; foo = print; foo((), 'Hi there')
would print a newline, bind foo to the builtin print function, and invoke the latter via foo,
(using () to indicate default outfile). None could also be used to indicate default outfile.
I just picked () as more flexibly adaptable to what I hadn't thought of yet re specifying outfile ;-)
Maybe a keyword arg would be better yet. I.e., as in def print(*args **kw) with
outfile=kw.get('outfile', sys.stdout). But that's an implementation detail.

>which would clearly produce two newlines and raises the question what the
>inner print gets evaluated to so that the outer one wouldn't print
>anything.
Not applicable. See above for translation explanation.

>
> While that would be sort of accetable, what you suggest makes print
>ambigious - depending on the context. And above that:
No, you have misunderstood (I wasn't clear enough) my suggestion. No ambiguity,
but yes, a print name token as the leading token of a statement is interpreted
specially. You could interpret print(x) differently from print (x) analogously
to 123.__doc__ (illegal) vs 123 .__doc__ which gives you int docs.
>
>>>> len
><built-in function len>
>>>> 
>
>has no sideeffects whatsoever, where
>
>>>> print
>
>>>>
>
>clearly has.
as does

    sys.stdout.write('\n')
       
so I guess I am missing your point.

>
>As BDFL has already said, he regrets to have introduced print as a statement
>- but as he did, there is no really elegant way around having print as a
>reserved keyword. One _can_ think of taking context into account to either
>interpret print as keyword or as identifier while parsing - the question
>is: Is it worth it? IMHO no - but as Alex said: If it makes you happy,
>implement it  :) The same applies to all other keywords as well, btw.
It doesn't seem that complex a context for print, but I haven't thought
about the other keywords yet (no time really for this even ;-/). I wonder
what a comprehensive writeup of python name semantics would reveal,
discussing all the different name spaces and ways that names are searched for
and used in various contexts.

Regards,
Bengt Richter