On Sat, Mar 12, 2011 at 8:59 AM, Nick Coghlan <ncogh...@gmail.com> wrote: > On Sat, Mar 12, 2011 at 8:33 AM, Laura Creighton <l...@openend.se> wrote: >> For those of you not at the Language Summit at PyCON the day before >> yesterday, >> there was talk of identifying non-portable behaviour, such as relying on >> CPython's reference counting garbage collector to close files for you as >> soon as they become unreachable. And then warning about them. >> >> We have a real live user who has a large code base that relies on >> the CPython behaviour that an object's __radd__ method will take precedence >> over a list's inplace add behaviour. >> >> The thread with the whole gory details begins here: >> http://codespeak.net/pipermail/pypy-dev/2011q1/006958.html >> >> My inclination is to declare code that relies on this as broken, rather >> than patch every wretched container type in PyPy. Can this become >> blessed as a 'you shouldn't have done this'? > > Given that the meat of the difference in semantics lies in the > CPython-specific distinction between nb_add and sq_concat, I'm > inclined to agree with you. > > I'm actually tempted to call the current CPython semantics flatout > *wrong*. When a given operation has multiple C level slots, shouldn't > we be checking all the LHS slots before checking any of the RHS slots? > There's nothing in the language spec that I'm aware of that justifies > us doing otherwise. > > (obviously, history now means that changing our behaviour would > require a deprecation period)
Yeah, indeed, on everything you said. The code dispatching based on internal slots is horribly ad-hoc and likely wrong in subtle ways. Has any of this improved in Python 3? -- --Guido van Rossum (python.org/~guido) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
