[Python-Dev] Splitting something into two steps produces different behavior from doing it in one fell swoop in Python 2.6.2

Roy Hyunjin Han starsareblueandfaraway at gmail.com
Mon Dec 14 22:04:56 CET 2009


On Fri, Dec 11, 2009 at 7:59 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> It follows the standard left-to-right evaluation order within an expression:
>
> <subexpr1>(<subexpr2>)
>
> (i.e. a function call always determines which function is going to be
> called before determining any arguments to be passed)
>
> Splitting it into two lines then clearly changes the evaluation order:
>
> temp = <subexpr2>
> <subexpr1>(temp)
>
> I'm not sure what behaviour could be suggested as being more intuitive -
> the problem in this case arose due to both referencing and mutating the
> same object in a single statement, which is always going to be
> problematic from an ordering point of view, since it depends on subtle
> details of statement definitions that people often won't know. Better to
> split the mutation and the reference into separate statements so the
> intended order is clear regardless of how well the reader knows the
> subtleties of Python's evaluation order.
>
> Cheers,
> Nick.
>

Thanks for the explanation, Nick.  I understand what is happening now.
 y[1].update resolves to the update() method of the old set referenced
by y[1], but this set is then popped so that the update() manages to
change the old set, but not the new one that is returned by any
subsequent reference to y[1].  I suppose I will have to keep this in
two statements.  A similar thing happened with the SWIG extensions for
GDAL, in which one had to separate statements so that SWIG objects
were not destroyed prematurely, i.e. no more one-liners.


More information about the Python-Dev mailing list