Re: [pypy-dev] Ordered dict in PyPy
Can we talk the CPython developers into raising RunTimeError for concurrent modifications? Laura
Hi Laura, On 11 January 2015 at 19:57, Laura Creighton <lac@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.
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 <arigo@tunes.org> wrote:
Hi Laura,
On 11 January 2015 at 19:57, Laura Creighton <lac@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
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.gaynor@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 <arigo@tunes.org> wrote:
Hi Laura,
On 11 January 2015 at 19:57, Laura Creighton <lac@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
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 <fijall@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.gaynor@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 <arigo@tunes.org> wrote:
Hi Laura,
On 11 January 2015 at 19:57, Laura Creighton <lac@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
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 <fijall@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 <fijall@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.gaynor@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 <arigo@tunes.org> wrote:
Hi Laura,
On 11 January 2015 at 19:57, Laura Creighton <lac@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
Hi all, Thanks for the feedback. It looks like the general opinion is to raise RuntimeError when detecting changes. I'll do that then. About '__reversed__', I suppose it should be implemented the same way, with an RPython-provided iterator which raises RuntimeError too. A bientôt, Armin.
IMHO, there's a part of an old "saying": [...] Errors should never pass silently. Unless explicitly silenced. So I'd say better to have users deal with the RuntimeError, and document it in the CPython diferences page. 2015-01-11 14:26 GMT-05:00 Alex Gaynor <alex.gaynor@gmail.com>:
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 <arigo@tunes.org> wrote:
Hi Laura,
On 11 January 2015 at 19:57, Laura Creighton <lac@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
participants (5)
-
Alex Gaynor -
Armin Rigo -
Laura Creighton -
Maciej Fijalkowski -
Samuel Villamonte