The PR for this looks good to go:
https://github.com/python/cpython/pull/13612
But, I still have no idea how it works for the OP's original test
case. So, if you have at least 80 GB of RAM to try it, I added
`arena.py` to the BPO report:
https://bugs.python.org/issue37029
That adds code to
On Thu, May 30, 2019 at 4:28 PM Greg Ewing
wrote:
> Nick Coghlan wrote:
> > So for me, getting rid of write backs via exec and "import *" was a
> > matter of "Yay, we finally closed those unfortunate loopholes" rather
> > than being any kind of regrettable necessity.
>
> If that were the
Given the flurry of discussion that happened this week, and that the PR
switching the PEP to use independent snapshots hasn't even been landed, I'm
skeptical that it's wise to attempt to get this in before beta 1 even if
you were to resolve the segfaults.
On Thu, May 30, 2019 at 4:24 PM Nick
Nick Coghlan wrote:
So for me, getting rid of write backs via exec and "import *" was a
matter of "Yay, we finally closed those unfortunate loopholes" rather
than being any kind of regrettable necessity.
If that were the reasoning, the principled thing to do would be
to raise an exception if
Hi folks,
The reference implementation for PEP 558 (my attempt to fix the interaction
between tracing functions and closure variables) is currently segfaulting
somewhere deep in the garbage collector, and I've found that there's an
issue with the PyEval_GetLocals() API returning a borrowed
On Fri., 31 May 2019, 5:20 am Xavier de Gaye, wrote:
> Currently f_locals is documented as readonly [1].
>
Read-only in the sense that you can't rebind it to point to a different
object - the dict it points to is mutable.
> The PEP says:
> > * "Don't change what isn't broken": the current
Currently f_locals is documented as readonly [1].
The PEP says:
* "Don't change what isn't broken": the current tracing mode problems are caused
by a requirement that's specific to tracing mode (support for external
rebinding of function local variable references), so it made sense to also
On Thu, 30 May 2019 at 09:12, Greg Ewing wrote:
>
> Nick Coghlan wrote:
> > If there was a compelling use case for letting "a = 1; exec(src);
> > print(a)" print something other than "1" at function scope, then I'd
> > be more amenable to the idea of the associated compatibility break and
> >
