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 5/27/19 2:05 PM, Terry Reedy wrote:
> On 5/27/2019 9:52 AM, Richard Damon wrote:
>> On 5/27/19 9:12 AM, Terry Reedy wrote:
>
>>> I believe that the situation is or can be thought of as this: there is
>>> exactly 1 function locals dict.
>
> per function invocation, or more generally, as Guido sai
On 5/27/2019 9:52 AM, Richard Damon wrote:
On 5/27/19 9:12 AM, Terry Reedy wrote:
I believe that the situation is or can be thought of as this: there is
exactly 1 function locals dict.
per function invocation, or more generally, as Guido said, per stack
frame. This part is obvious to me, b
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
On Mon, 27 May 2019 at 16:11, Guido van Rossum wrote:
>
> No, there's only one locals() dict *per stack frame*. So no worries about
> concurrency.
Again, if the PEP is about formalising the behaviour as language
mandated, this is worth documenting explicitly.
Paul
___
This whole vexing issue isn't going to be solved with any simple fix. A
tool that could identify upcoming trouble spots might or might not be
helpful.
Or perhaps it could be implemented as a __future__ feature, so that those
who choose not to use it during development see no change.
The primary e
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
No, there's only one locals() dict *per stack frame*. So no worries about
concurrency.
On Mon, May 27, 2019 at 6:54 AM Richard Damon
wrote:
> On 5/27/19 9:12 AM, Terry Reedy wrote:
> > On 5/27/2019 3:18 AM, Greg Ewing wrote:
> >> Chris Angelico wrote:
> >>> Except that it does. After calling loc
On Mon, 27 May 2019 09:27:33 -0400
David Mertz wrote:
> On Sun, May 26, 2019 at 11:17 PM Steven D'Aprano
> wrote:
>
> > > Nobody reads warnings.
> >
> > If nobody reads warnings, we should just remove the warnings module and
> > be done with it. That should probably be a PEP.
> >
>
> We'll
Hi,
Thanks Thomas for accepting my PEP :-)
Thanks everyone who was involved in discussions since it started July
2018! For the first version of my PEP 587, I tried to design an API as
small as possible, but it was clear that it didn't fit all use cases.
Slowly, I extended and adjusted the API to
On 27.05.2019 4:55, Steven D'Aprano wrote:
On Sun, May 26, 2019 at 04:03:11PM +0300, Ivan Pozdeev via Python-Dev wrote:
On 24.05.2019 9:55, Steven D'Aprano wrote:
I don't know if this is a good idea or a terrible idea or somewhere in
between, so I'm throwing it out to see if anyone likes it.
[
On 5/27/19 9:12 AM, Terry Reedy wrote:
> On 5/27/2019 3:18 AM, Greg Ewing wrote:
>> Chris Angelico wrote:
>>> Except that it does. After calling locals() a second time, the result
>>> of the *first* call will be updated to reflect changes.
>>
>> Yeow. That's *really* unintuitive. There had better b
On Sun, May 26, 2019 at 11:17 PM Steven D'Aprano
wrote:
> > Nobody reads warnings.
>
> If nobody reads warnings, we should just remove the warnings module and
> be done with it. That should probably be a PEP.
>
We'll have to start issuing a PendingDeprecationWarning when folk import
the `warning
On 5/27/2019 3:18 AM, Greg Ewing wrote:
Chris Angelico wrote:
Except that it does. After calling locals() a second time, the result
of the *first* call will be updated to reflect changes.
Yeow. That's *really* unintuitive. There had better be an extremely
good reason for this behaviour.
I be
Chris Angelico wrote:
Except that it does. After calling locals() a second time, the result
of the *first* call will be updated to reflect changes.
Yeow. That's *really* unintuitive. There had better be an extremely
good reason for this behaviour.
--
Greg
__
20 matches
Mail list logo
