I think we should avoid doing extras copies, it creates weird scenarios where the performance is randomly worse on PyPy, which can be very hard to debug.
Alex On Sun Jan 11 2015 at 11:51:00 AM Maciej Fijalkowski <fij...@gmail.com> wrote: > btw, I'm also ok with reversed being implemented by simply making a copy > > On Sun, Jan 11, 2015 at 9:37 PM, Maciej Fijalkowski <fij...@gmail.com> > wrote: > > I'm with Alex on that - raising RuntimeError is a good behavior when > > "you're not supposed to do that" happens. I would go with 1) as > > opposed to 2) > > > > On Sun, Jan 11, 2015 at 9:26 PM, Alex Gaynor <alex.gay...@gmail.com> > wrote: > >> 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 > >> >
_______________________________________________ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev
