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 trac
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 Sun, 26 May 2019 at 00:37, Guido van Rossum wrote:
>
> This looks great.
>
> I only have two nits with the text.
>
> First, why is the snapshot called a "dynamic snapshot"? What exactly is
> dynamic about it?
The dynamic part comes in if you call locals() twice: because it
returns the same ma
I'm guessing the reason is to remove the overhead of keeping the dictionary
up to date during function execution when no Python code needs access to it.
On Mon, May 27, 2019 at 8:10 PM Richard Damon
wrote:
> On 5/27/19 2:05 PM, Terry Reedy wrote:
> > On 5/27/2019 9:52 AM, Richard Damon wrote:
>
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, 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
___
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 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 09:20:53PM +1000, Chris Angelico wrote:
> Sure, but this PEP is all about defining things that weren't
> previously defined, so I wanted to clarify intent rather than current
> behaviour.
As I understand it, the intent is to:
- fix some annoyances/bugs involved when you h
On Sun, 26 May 2019 at 12:23, Chris Angelico wrote:
>
> On Sun, May 26, 2019 at 8:07 PM Steven D'Aprano wrote:
> > On Sun, May 26, 2019 at 08:44:33AM +1000, Chris Angelico wrote:
> >
> > > From my reading of the description, you could also "assert a is b" -
> > > is that correct?
> >
> > Yes, tha
On Sun, May 26, 2019 at 8:07 PM Steven D'Aprano wrote:
> On Sun, May 26, 2019 at 08:44:33AM +1000, Chris Angelico wrote:
>
> > From my reading of the description, you could also "assert a is b" -
> > is that correct?
>
> Yes, that's already the behaviour.
>
> py> def demo():
> ... a = locals()
On Sun, May 26, 2019 at 08:04:11PM +1000, Steven D'Aprano wrote:
> Richard, your email seems to have introduced a spurious "SPAM" label
[...]
> edit the subject line to remove the
> label? Thanks. I've done so for this response
Oops. Done now.
--
Steven
__
(And this time I will remember to remove the SPAM label...)
On Sun, May 26, 2019 at 08:44:33AM +1000, Chris Angelico wrote:
> From my reading of the description, you could also "assert a is b" -
> is that correct?
Yes, that's already the behaviour.
py> def demo():
... a = locals()
... b
That's a good fine point that the PEP could call out, but just adding
"dynamic" in front of "snapshot" everywhere doesn't tell me any of that.
Given that the code calling locals() must of necessity live in the same
function body (except for the special case of trace functions), I don't
think that
On Sat, May 25, 2019, 07:38 Guido van Rossum wrote:
> This looks great.
>
> I only have two nits with the text.
>
> First, why is the snapshot called a "dynamic snapshot"? What exactly is
> dynamic about it?
>
It's dynamic in that it can spontaneously change when certain other events
happen. For
On 5/25/2019 10:36 AM, Guido van Rossum wrote:
This looks great.
I agree. I understand and have tried to explain normal operation
multiple times. The proposed new doc looks better than anything I ever
wrote. (I never even thought about locals() with tracing on.) The
improved clarity well
This looks great.
I only have two nits with the text.
First, why is the snapshot called a "dynamic snapshot"? What exactly is
dynamic about it?
Second, you use the word "mapping" a lot. Would you mind changing that to
"mapping object" in most places? Especially in the phrase "each call to
``loca
Hi,
On Thu, 23 May 2019 at 17:28, Steve Dower wrote:
> On 23May2019 0636, Nick Coghlan wrote:
> > However, I think the PR does show that the proposed technique can be
> > implemented without too much additional code complexity, and will
> > hopefully be adaptable for all implementations that emul
On 23May2019 0636, Nick Coghlan wrote:
However, I think the PR does show that the proposed technique can be
implemented without too much additional code complexity, and will
hopefully be adaptable for all implementations that emulate the frame
API at all.
Much excitement!
One of the things I l
On Wed, 22 May 2019 at 00:51, Nick Coghlan wrote:
> P.S. I'm away this weekend, so I expect the reference implementation
> to be done late next week, and I'd be submitting the PEP to Nathaniel
> for formal pronouncement at that point. However, I'm posting this
> thread now so that there's more tim
21 matches
Mail list logo
