Python Oddity - print a reserved name

[Diez B. Roggisch]

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

I understood that that was what you _wanted_ it to be - but how do you want
to parse that? It would involve saying "first encounter of print is a
keyword, then an identifier" - that condition is reset after the statement,
so to speak the next line or a semicolon.

That surely is possible, but has to be done _after_ lexcal analysis - which
makes things more complicated as necessary, for a very questionable
benefit.

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

How shall that work? Right now, print ; print produces two newlines. Do you
want to alter that behaviour? Do you want to complicate parsing even more
by saying that print on the right side of an expression is the name,
otherwise its executed? 
That would be inconsistent - every newby would ask why 

>>> foo

then isn't evaluated, but yields <funtion foo>, whereas 

>>> print

produces a nl.


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

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


The point is that two things that look alike should behave the same for
reasons of orthogonality  - having as special-case of print here does
produce behaviour that yields to confusion, as I said before. That is of
course also true right now - but because print beeing a reserved keyword,
nobody falls into any traps here - its just forbidden. 


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

Well, its certainly more complicated than just altering the lexical phase -
it requrires a post-reduction step - deep in the parser.

-- 
Regards,

Diez B. Roggisch