On Tue, Sep 5, 2017 at 10:31 AM, Koos Zevenhoven <k7hoven@gmail.com> wrote:
On Tue, Sep 5, 2017 at 8:24 PM, Yury Selivanov <yselivanov.ml@gmail.com> wrote:
On Tue, Sep 5, 2017 at 9:12 AM, Koos Zevenhoven <k7hoven@gmail.com> wrote:
On Tue, Sep 5, 2017 at 6:53 PM, Yury Selivanov <yselivanov.ml@gmail.com> wrote:
On Tue, Sep 5, 2017 at 8:35 AM, Koos Zevenhoven <k7hoven@gmail.com> wrote:
On Tue, Sep 5, 2017 at 3:49 AM, Nathaniel Smith <njs@pobox.com> wrote: [..]
I think PEP 550 is sufficient to allow implementing all your proposed APIs (and that if it isn't, that's a bug in PEP 550).
That's not true either. The LocalContext-based semantics introduces scope barriers that affect *all* variables. You might get close by putting just one variable in a LogicalContext and then nest them, but PEP 550 does not allow this in all cases. With the addition of PEP 521 and some trickery, it might.
I think you have a wrong idea about PEP 550 specification. I recommend you to reread it carefully, otherwise we can't have a productive discussion here.
I'm sorry, by LocalContext I meant LogicalContext, and by "nesting" them, I meant stacking them. It is in fact nesting in terms of value scopes.
I don't actually care if you use the latest terminology. You seem to have a wrong idea about how PEP 550 really works (and its full semantics), because things you say here about it don't make any sense.
In PEP 550, introducing a new LogicalContext on the ExecutionContext affects the scope of any_ var.set(value) for * any * any_var . Does that not make sense?
It does. But your other sentence ".. You might get close by putting just one variable in a LogicalContext and then nest them, but PEP 550 does not allow this in all cases .." does not. Yury