Thanks for quick reply!
On Mon, Jan 12, 2015 at 1:50 AM, Armin Rigo wrote:
> Hi Yuriy,
>
> On 11 January 2015 at 23:38, Yuriy Taraday wrote:
> > - Did something change wrt can_enter_jit since that code had been
> written? I
> > mean besides check that raises that error [3].
>
> No. There are p
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.
___
Hi Yuriy,
On 11 January 2015 at 23:38, Yuriy Taraday wrote:
> - Did something change wrt can_enter_jit since that code had been written? I
> mean besides check that raises that error [3].
No. There are probably cases where that check fails but the code was
still correct; I bet it was the case i
Hello.
I'm poking around lang-js [0] looking if I can make it better (just for
fun).
First issue I've stumbled upon is mysterious "Bad can_enter_jit()
placement" error. It looks like when we do a jump in user code [1], we
should do "can_enter_jit" with new instruction pointer, not the old one.
I'v
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
wrote:
> btw, I'm also ok with reversed being implemented by simply making a copy
>
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 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,
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 :
> IMO, it's clear that CPython inte
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 wrote:
> IMO, it's clear that CPython intends this to be "undefined behavior",
> raising a RuntimeError i
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 Orde
Hi Laura,
On 11 January 2015 at 19:57, Laura Creighton 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 Ru
Can we talk the CPython developers into raising RunTimeError for
concurrent modifications?
Laura
___
pypy-dev mailing list
pypy-dev@python.org
https://mail.python.org/mailman/listinfo/pypy-dev
Hi all,
The all-ordered-dicts branch is not quite ready for merging, but
getting there. In one word, it makes all dicts ordered by default, by
a subtle change of the internal model which also makes them *more*
compact.
An annoying detail is the OrderedDict subclass. We can simplify it a
lot in P
12 matches
Mail list logo
