sturlamolden wrote: > On Dec 12, 3:54 pm, Steve Holden <st...@holdenweb.com> wrote: [...] >> The interpreter "should not" have a GIL. > >> The tuple "should" check that >> it is actually being mutated. How? > > In Python it would be something similar to: > > def __setitem__(self, index, value): > if _buf[index] is not value: # given that _buf is the tuple's > internal buffer > raise TypeError, 'tuple' object does not support item > assignment > > It should be the tuple's __setitem__ that was invoked here, not > __iadd__, or the parser is faulty. > OK, so now you are proposing to alter the parser, and possibly the implementation of the INPLACE_ADD opcode in eval.c, so can you give us the patch for those, please?
This is exactly the point I was trying to make. It's easy to stand on the sidelines and make sensible- or even intelligent-sounding suggestions about how to change Python. But inside the interpreter there's a maze of twisty little passages all alike (or similar complexity), and hand-waving doesn't get you anywhere. Discussion of such behavior as a "bug" is also pejorative, since the current semantics are the way they are by design. You are therefore disagreeing with the design of Python rather than discussing a bug in its implementation. That also raises the issues of how you get Jython and IronPython to implement the same semantics, and whether you care about the millions of lines of code that already assumes the current behavior. You've got a lot of work to do ... regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ -- http://mail.python.org/mailman/listinfo/python-list