On Wed, May 29, 2019, at 01:25, Nick Coghlan wrote:
> Having a single locals() call de-optimize an entire function would be
> far from ideal.
What if there were a way to explicitly de-optimize a function, rather than
guessing the user's intent based on looking for locals and exec calls (both of
On 2019-06-02 13:51, Steven D'Aprano wrote:
On Sun, Jun 02, 2019 at 11:52:02PM +1200, Greg Ewing wrote:
Armin Rigo wrote:
>You have the occasional big function that benefits a lot from being
>JIT-compiled but which contains ``.format(**locals())``.
There should be a lot less need for that now t
On Sun, Jun 02, 2019 at 11:52:02PM +1200, Greg Ewing wrote:
> Armin Rigo wrote:
> >You have the occasional big function that benefits a lot from being
> >JIT-compiled but which contains ``.format(**locals())``.
>
> There should be a lot less need for that now that we have f-strings.
I think you'r
Armin Rigo wrote:
You have the occasional big function that benefits a lot from being
JIT-compiled but which contains ``.format(**locals())``.
There should be a lot less need for that now that we have f-strings.
--
Greg
___
Python-Dev mailing list
Py
Hi,
On Wed, 29 May 2019 at 08:07, Greg Ewing wrote:
> Nick Coghlan wrote:
> > Having a single locals() call de-optimize an entire function would be
> > far from ideal.
>
> I don't see what would be so bad about that. The vast majority
> of functions have no need for locals().
You have the occasi
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 reasonin
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 an
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
> > pote
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
potential performance regression in other implementations.
However, th
On Wed, 29 May 2019 at 16:08, Greg Ewing wrote:
>
> Nick Coghlan wrote:
> > Having a single locals() call de-optimize an entire function would be
> > far from ideal.
>
> I don't see what would be so bad about that. The vast majority
> of functions have no need for locals().
If there was a compell
Indeed.
On Tue, May 28, 2019 at 11:07 PM Greg Ewing
wrote:
> Nick Coghlan wrote:
> > Having a single locals() call de-optimize an entire function would be
> > far from ideal.
>
> I don't see what would be so bad about that. The vast majority
> of functions have no need for locals().
>
> --
> Gre
Nick Coghlan wrote:
Having a single locals() call de-optimize an entire function would be
far from ideal.
I don't see what would be so bad about that. The vast majority
of functions have no need for locals().
--
Greg
___
Python-Dev mailing list
Pytho
On Wed., 29 May 2019, 2:29 pm Guido van Rossum, wrote:
> So why is it “hellish” for JITs if locals() returns a proxy, while
> frame.f_locals being a proxy is okay?
>
As I understand it, they already drop out of compiled mode if they detect
that the code is tinkering with frame objects.
Having a
So why is it “hellish” for JITs if locals() returns a proxy, while
frame.f_locals being a proxy is okay?
On Tue, May 28, 2019 at 9:12 PM Nick Coghlan wrote:
> (I'll likely write a more detailed reply once I'm back on an actual
> computer, but wanted to send an initial response while folks in the
(I'll likely write a more detailed reply once I'm back on an actual
computer, but wanted to send an initial response while folks in the US are
still awake, as the detailed reply may not be needed)
Thanks for this write-up Nathaniel - I think you've done a good job of
capturing the available design
On Tue, May 28, 2019 at 6:48 PM Greg Ewing wrote:
>
> Nathaniel Smith wrote:
> > - [proxy]: Simply return the .f_locals object, so in all contexts
> > locals() returns a live mutable view of the actual environment:
> >
> > def locals():
> > return get_caller_frame().f_locals
>
> Not sure I
Nathaniel Smith wrote:
- [proxy]: Simply return the .f_locals object, so in all contexts
locals() returns a live mutable view of the actual environment:
def locals():
return get_caller_frame().f_locals
Not sure I quite follow this -- as far as I can see, f_locals
currently has the sam
On Tue, May 28, 2019 at 08:37:17AM +0100, Paul Moore wrote:
> Of course, all of this is only if we have decided to formalise the
> semantics and change CPython to conform. I've never personally been
> affected by any of the edge cases with locals(), so on a purely
> personal basis, I'm equally hap
On Tue, 28 May 2019 at 06:00, Nathaniel Smith wrote:
> - There's the "justified" action-at-a-distance that currently happens
> at module scope, where locals().__setitem__ affects variable lookup,
> and variable mutation affects locals().__getitem__. This can produce
> surprising results if you pa
On Mon, May 27, 2019 at 9:18 PM Guido van Rossum wrote:
>
> Note that the weird, Action At A Distance behavior is also visible for
> locals() called at module scope (since there, locals() is globals(), which
> returns the actual dict that's the module's __dict__, i.e. the Source Of
> Truth. So
Note that the weird, Action At A Distance behavior is also visible for
locals() called at module scope (since there, locals() is globals(), which
returns the actual dict that's the module's __dict__, i.e. the Source Of
Truth. So I think it's unavoidable in general, and we would do wise not to
try a
On 5/27/2019 7:28 PM, Steven D'Aprano wrote:
On the other hand, locals() currently returns a dict everywhere. It
might be surprising for it to start returning a proxy object inside
functions instead of a dict.
I thought the proxy object sounded more useful... how different is it in
use from a di
On Mon, May 27, 2019 at 08:15:01AM -0700, Nathaniel Smith wrote:
[...]
> I'm not as sure about the locals() parts of the proposal. It might be
> fine, but there are some complex trade-offs here that I'm still trying
> to wrap my head around. The rest of this document is me thinking out
> loud to tr
OK, I apologize for not catching on to the changed semantics of f_locals
(which in the proposal is always a proxy for the fast locals and the
cells). I don't know if I just skimmed that part of the PEP or that it
needs calling out more.
I'm assuming that there are backwards compatibility concerns,
On Mon, May 27, 2019 at 9:16 AM Guido van Rossum wrote:
>
> I re-ran your examples and found that some of them fail.
>
> On Mon, May 27, 2019 at 8:17 AM Nathaniel Smith wrote:
[...]
>> The interaction between f_locals and and locals() is also subtle:
>>
>> def f():
>> a = 1
>> loc =
I re-ran your examples and found that some of them fail.
On Mon, May 27, 2019 at 8:17 AM Nathaniel Smith wrote:
> First, I want to say: I'm very happy with PEP 558's changes to
> f_locals. It solves the weird threading bugs, and exposes the
> fundamental operations you need for debugging in a si
First, I want to say: I'm very happy with PEP 558's changes to
f_locals. It solves the weird threading bugs, and exposes the
fundamental operations you need for debugging in a simple and clean
way, while leaving a lot of implementation flexibility for future
Python VMs. It's a huge improvement over
27 matches
Mail list logo
