IMO, it's clear that CPython intends this to be "undefined behavior", raising a RuntimeError is a perfectly acceptable undefined behavior IMO -- better than corrupting the data.
For __eq__ and __reversed__ and popitem(last=False) we can just have functions in __pypy__ and call them from class OrderedDict(dict): in collections I think? Alex On Sun Jan 11 2015 at 11:20:55 AM Armin Rigo <ar...@tunes.org> wrote: > Hi Laura, > > On 11 January 2015 at 19:57, Laura Creighton <l...@openend.se> wrote: > > Can we talk the CPython developers into raising RunTimeError for > > concurrent modifications? > > No, we can't expect them to change that: > http://bugs.python.org/issue19414 shows they have no plan to have > well-defined behavior (either RuntimeError or well-defined results). > > So for us, the question is if it makes sense for us to break > compatibility with CPython 2.7 in this undocumented aspect by arguing > that CPython's sometimes bogus results shows it was never meant to > work at all (which is true), or if instead we should go the opposite > way and offer some well-defined results that generalizes the partially > working results of CPython (which would make people happy but is > harder to implement). > > Note that I would be fine if we can't find any existing program that > relies on this. Then we can decide to implement the RuntimeError > solution. If and when somebody files a PyPy bug report, we can argue > again. > > > A bientôt, > > Armin. > _______________________________________________ > pypy-dev mailing list > pypy-dev@python.org > https://mail.python.org/mailman/listinfo/pypy-dev >
_______________________________________________ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev