Re: print ambiguity

Joe Mason wrote:

> Obviously I missed some discussion between then and now.  How did the
> proposal get revived?  Can I request we kill it again?  Requiring a
> whole new opcode seems like overkill.

We were voting on it and the vote was pretty much a tie.  Lenard pointed out
this problem:

    print (1,2,3)

Is the above statement printing a tuple or printing the arguments 1, 2, and
3?

When I saw this ambiguity I announced the idea as dead.

Then Paul switched his vote from no to yes and argued that that printing a
tuple constant was a useless case.  You can always do "print((1,2,3))".  He
also argued for not allowing just any function to be used as a command,
which was my original proposal.  His proposal was that you had to specify
that a function was "command-enabled".

So Paul changed the vote from a tie to a win and I implemented the new
proposal.

The latest build now works like this:

1) Only functions that have an attribute named "command_" can be used in the
command format.  Print is the only built-in that comes that way right now.
You may create your own command this way:

    def prterr(*args):
            "command to print to stderr"
            prterr.command_ = True
            stdErr.print(*args)

    prterr "this is going to stderr", x

2) The command format is only allowed when used on a line by itself.

    x = print a, b, c  # not allowed

    print a, b, c  # ok

    x = print(a, b, c)  # ok

3) print (a, b, c) will always be interpreted as a print call, not printing
a tuple.

4) A variable by itself on a line will be a command function call if it has
the "command_" attribute, otherwise it will represent the expression
evaluation of the variable as normal.  (New rule from this latest
discussion).

The moral of the story?  You shouldn't have left the mailing list for so
long.  :-)