[Python-Dev] Re: Comments on PEP 558

On Wed, 28 Jul 2021, 8:13 pm Mark Shannon, wrote: > > > On 28/07/2021 1:03 am, Nick Coghlan wrote: > > > > > > On Wed, 28 Jul 2021, 1:50 am Mark Shannon, > > wrote: > > > > Hi Nick, > > > > On 27/07/2021 2:29 pm, Nick Coghlan wrote: > > > > > > > > >

[Python-Dev] Re: Comments on PEP 558

On 28/07/2021 1:03 am, Nick Coghlan wrote: On Wed, 28 Jul 2021, 1:50 am Mark Shannon, > wrote: Hi Nick, On 27/07/2021 2:29 pm, Nick Coghlan wrote: > > > The reference documentation should be precise as well, since that is > what other impl

[Python-Dev] Re: Comments on PEP 558

On Wed, 28 Jul 2021, 1:50 am Mark Shannon, wrote: > Hi Nick, > > On 27/07/2021 2:29 pm, Nick Coghlan wrote: > > > > > > The reference documentation should be precise as well, since that is > > what other implementations will be following. > > > > What semantics do you feel are left unspecified? >

[Python-Dev] Re: Comments on PEP 558

Hi Nick, On 27/07/2021 2:29 pm, Nick Coghlan wrote: (I'm not sure Mailman will get the threading right when I've received the original email directly, so apologies in advance if this reply creates a 2nd thread) On Mon, 26 Jul 2021 at 23:57, Mark Shannon wrote: Hi, First of all let me say tha

[Python-Dev] Re: Comments on PEP 558

(I'm not sure Mailman will get the threading right when I've received the original email directly, so apologies in advance if this reply creates a 2nd thread) On Mon, 26 Jul 2021 at 23:57, Mark Shannon wrote: > > Hi, > > First of all let me say that I agree with the aims of PEP 558 and most > of t

[Python-Dev] Re: Comments on PEP 558

Hi Mark, On 04.02.21 12:47, Mark Shannon wrote: Hi Sven, On 04/02/2021 9:06 am, Sven R. Kunze wrote: As long as it is possible to **write** to existing keys to **add new keys** to frame.f_locals, I am actually quite happy. Out of interest, why would you want to add new keys to the locals of

[Python-Dev] Re: Comments on PEP 558

Hi Sven, On 04/02/2021 9:06 am, Sven R. Kunze wrote: On 03.02.21 23:37, Nick Coghlan wrote: No, PEP 558 doesn't remove it, it enhances it to be a live view of the frame state instead of an inconsistently updated snapshot. As long as it is possible to **write** to existing keys to **add new

[Python-Dev] Re: Comments on PEP 558

On 03.02.21 23:37, Nick Coghlan wrote: No, PEP 558 doesn't remove it, it enhances it to be a live view of the frame state instead of an inconsistently updated snapshot. As long as it is possible to **write** to existing keys to **add new keys** to frame.f_locals, I am actually quite happy.

[Python-Dev] Re: Comments on PEP 558

On Wed, 3 Feb 2021, 10:16 pm Sven R. Kunze, wrote: > Hi Mark, > > I've been working on a project heavily relying on frame.f_locals. > > Are you planning to remove it? > No, PEP 558 doesn't remove it, it enhances it to be a live view of the frame state instead of an inconsistently updated snapsho

[Python-Dev] Re: Comments on PEP 558

Hi Mark, I've been working on a project heavily relying on frame.f_locals. Are you planning to remove it? On 30.01.21 13:18, Mark Shannon wrote: Given that f_locals is broken, why is keeping compatibility for this obscure, and probably unused case worthwhile? The break in compatibility wi

[Python-Dev] Re: Comments on PEP 558

On Sun, 31 Jan 2021 at 14:09, Nick Coghlan wrote: > On Sat, 30 Jan 2021, 10:55 pm Nick Coghlan, wrote: >> On Sat, 30 Jan 2021, 10:18 pm Mark Shannon, wrote: >>> The break in compatibility with locals() seems much more intrusive, yet >>> you are OK with that (as am I). >> PyEval_GetLocals() is pa

[Python-Dev] Re: Comments on PEP 558

On Sat, 30 Jan 2021, 10:55 pm Nick Coghlan, wrote: > > > On Sat, 30 Jan 2021, 10:18 pm Mark Shannon, wrote: > >> >> > >> The break in compatibility with locals() seems much more intrusive, yet >> you are OK with that (as am I). >> > > PyEval_GetLocals() is part of the stable ABI and returns a bo

[Python-Dev] Re: Comments on PEP 558

On Sat, 30 Jan 2021, 10:18 pm Mark Shannon, wrote: > Hi Nick, > > On 30/01/2021 4:44 am, Nick Coghlan wrote: > > On Sat, 30 Jan 2021 at 10:30, Nick Coghlan wrote: > >> On Sat, 30 Jan 2021, 12:13 am Mark Shannon, wrote: > >>> With a direct proxy coherency is not an issue. > >> > >> For things in

[Python-Dev] Re: Comments on PEP 558

Hi Nick, On 30/01/2021 4:44 am, Nick Coghlan wrote: On Sat, 30 Jan 2021 at 10:30, Nick Coghlan wrote: On Sat, 30 Jan 2021, 12:13 am Mark Shannon, wrote: With a direct proxy coherency is not an issue. For things in the frame, it *is* a direct proxy - reads pull from the frame object, and w

[Python-Dev] Re: Comments on PEP 558

On Sat, 30 Jan 2021 at 10:30, Nick Coghlan wrote: > On Sat, 30 Jan 2021, 12:13 am Mark Shannon, wrote: >> With a direct proxy coherency is not an issue. > > For things in the frame, it *is* a direct proxy - reads pull from the frame > object, and writes go to both the frame object and the mappin

[Python-Dev] Re: Comments on PEP 558

On Sat, 30 Jan 2021, 12:13 am Mark Shannon, wrote: > Hi > > It is a lot more complex, because you need to worry about coherency. > With a direct proxy coherency is not an issue. > For things in the frame, it *is* a direct proxy - reads pull from the frame object, and writes go to both the frame

[Python-Dev] Re: Comments on PEP 558

Hi Nick, On 29/01/2021 1:21 pm, Nick Coghlan wrote: On Thu, 28 Jan 2021, 11:18 pm Mark Shannon, > wrote: Hi Nick, Regarding `f_locals` PEP 558 states: """ Instead of being a direct reference to the internal dynamic snapshot used to populate the inde

[Python-Dev] Re: Comments on PEP 558

On Thu, 28 Jan 2021, 11:18 pm Mark Shannon, wrote: > > Hi Nick, > > Regarding `f_locals` PEP 558 states: > > """ > Instead of being a direct reference to the internal dynamic snapshot > used to populate the independent snapshots returned by locals(), > frame.f_locals will be updated to instead re

[Python-Dev] Re: Comments on PEP 558 (Defined semantics for locals() )

On Sun, 16 Feb 2020 at 23:35, Nick Coghlan wrote: > On Mon., 10 Feb. 2020, 8:31 pm Mark Shannon, wrote: >> The proposed changes in PEP 558 are also backwards incompatible. >> I thought that was the point. The current implementation is broken in >> weird ways and we want to fix that. Since we need

[Python-Dev] Re: Comments on PEP 558 (Defined semantics for locals() )

On Tue., 18 Feb. 2020, 12:14 am Mark Shannon, wrote: > > Any function returning a borrowed reference is already broken, IMO. > Sadly there are quite a few of them :( > Might as well fix `PyEval_GetLocals()` as we are changing its semantics > anyway. > > A quick search of GitHub shows that most us

[Python-Dev] Re: Comments on PEP 558 (Defined semantics for locals() )

On 16/02/2020 1:35 pm, Nick Coghlan wrote: On Mon., 10 Feb. 2020, 8:31 pm Mark Shannon, > wrote: On 08/02/2020 11:49 am, Nick Coghlan wrote: > Unfortunately, the simplifications you propose would be backwards > incompatible - it's existing behaviour that

[Python-Dev] Re: Comments on PEP 558 (Defined semantics for locals() )

On Mon., 10 Feb. 2020, 8:31 pm Mark Shannon, wrote: > > On 08/02/2020 11:49 am, Nick Coghlan wrote: > > Unfortunately, the simplifications you propose would be backwards > > incompatible - it's existing behaviour that there's a real shared dict > > (even on optimised frames) where arbitrary extra

[Python-Dev] Re: Comments on PEP 558 (Defined semantics for locals() )

On 08/02/2020 11:49 am, Nick Coghlan wrote: Unfortunately, the simplifications you propose would be backwards incompatible - it's existing behaviour that there's a real shared dict (even on optimised frames) where arbitrary extra attributes can be stored (even though they don't become accessibl

[Python-Dev] Re: Comments on PEP 558 (Defined semantics for locals() )

Unfortunately, the simplifications you propose would be backwards incompatible - it's existing behaviour that there's a real shared dict (even on optimised frames) where arbitrary extra attributes can be stored (even though they don't become accessible as Python variables). I don't want to make fra