Not pessimistic enough, though! It _does_ invert the order of the top N
stack entries, but perhaps not so easy to repair.
In
tuple1 = tuple2
the Reference Manual guarantees left-to-right evaluation of tuple2, and
left-to-right binding in tuple1, but leaves unspecified whether, e.g.,
_all_ sub-expressions in tuple1 have to be evaluated after _all_ sub-
expressions in tuple2 have been evaluated. So the behavior of the
following mess isn't wholly defined, but _most_ of it's defined:
j = 0
def out():
global j
j = j + 1
return j
def f():
a, i, a[i + out()] = [out()]*10, out(), out()
print i, a
That prints
2 [1, 1, 1, 1, 1, 1, 3, 1, 1, 1]
today (implying that everything on the RHS is evaluated before any part
of anything on the LHS is evaluated).
Evaluating the RHS left-to-right, and pushing the results on the stack as
you go, leaves them in the wrong order for left-to-right binding of
the LHS, and byte-code doesn't support an elementary (read dirt-cheap)
stack operation that can worm around that. But changing the evaluation
order on either the LHS or the RHS would change the visible semantics.
stinking-stack-based-virtual-machines<grin>-ly y'rs - tim
Tim Peters tim@ksr.com
not speaking for Kendall Square Research Corp