I *do* use, x,y,z as common var names, and I was just about to suggest
"_", since I seem to be the only one useing that name for *anything at
all* ! :-) [ recalling the 'None = f()' thread... ] - and in fact,
since I was using it as a "junk" variable to 'void' my functions, there
is no conflict with giving it the same function automagically.
>
> Later we could invent more flexible schemes -- the most flexible being
> a user-defined function assigned to a variable in module sys that is
> called to print the value...
>
Note that <return> in Python already compiles into:
>>> import mytrace,sys
>>> sys.settrace( mytrace.trace )
>>>
('call', None)
<frame object at 2006acc8> <code object ? at 200772c8, file "<stdin>", line 0>
('<stdin>', -1)
0 SET_LINENO 0
3 LOAD_CONST 0 (None)
6 RETURN_VALUE
while: '>>> 1' is:
0 SET_LINENO 0
3 SET_LINENO 1
6 LOAD_CONST 0 (1)
9 PRINT_EXPR
10 LOAD_CONST 1 (None)
13 RETURN_VALUE
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.
Note that since 'print 1' compiles to:
0 SET_LINENO 0
3 SET_LINENO 1
6 LOAD_CONST 0 (1)
9 PRINT_ITEM
10 PRINT_NEWLINE
11 LOAD_CONST 1 (None)
14 RETURN_VALUE
i.e. it does a PRINT_ITEM, not a PRINT_EXPR, so rebinding
PRINT_EXPR should have no effects on explicit print statements.
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.
- Steve Majewski (804-982-0831) <sdm7g@Virginia.EDU>
- UVA Department of Molecular Physiology and Biological Physics