Steven:
> Another whole completely different approach would be to make
> PRINT_EXPR call a user-defined function. Rather than a command-line
> setting to set NO-PRINT, PRINT_EXPR could be bound to a null routine.
> Since this is changable within Python, it doesn't have the same
> problems that the command-line option has. ( Well - it does have
> some *different* problems, but... ) The value of '_' would be
> the value passed to print_expr.
That's exactly what I had in mind. But my compiler now generates
PRINT_EXPR only for interactive statements. If people adopt a
programming style of massively ignoring values returned from
functions, then having your print_expr() hook called for each such
case would be a massive performance hit! So for BW compat only, a
flag may still be in order. Only if people ask for it though --
personally I'm happy without it, I don't think I've written any code
that uses "expr" instead of "print `expr`".
> i.e. it does a PRINT_ITEM, not a PRINT_EXPR, so rebinding
> PRINT_EXPR should have no effects on explicit print statements.
That's right.
> There well may be a fatal flaw in this idea: it only just came to
> me and I haven't tried to sit down and think what might break it -
> but it may be an alternative worth considering.
Well apart from what I pointed out above I don't see a problem with
it. One use I can imagine for it would be to keep a log of the last N
recent values assigned to '_', e.g. sys.last[-1] might be the same as
_, sys.last[-2] might be the previous value, and so on. In fact you
should do the assignment to __main__._ inside the "hook" function as
well so the hook can be used to choose a different name for it as well
(pun intended).
--Guido van Rossum, CWI, Amsterdam <Guido.van.Rossum@cwi.nl>
URL: <http://www.cwi.nl/cwi/people/Guido.van.Rossum.html>