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

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:

() (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 = (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