[Python-Dev] Scope, not context? (was Re: PEP 550 v3 naming)
ncoghlan at gmail.com
Fri Aug 25 09:23:52 EDT 2017
On 25 August 2017 at 20:28, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Fri, 25 Aug 2017 15:36:55 +1000
> Nick Coghlan <ncoghlan at gmail.com> wrote:
>> On 24 August 2017 at 23:52, Barry Warsaw <barry at python.org> wrote:
>> > Guido van Rossum wrote:
>> >> On Tue, Aug 22, 2017 at 7:12 PM, Nathaniel Smith <njs at pobox.com> wrote:
>> >> I worry that that's going to lead more people astray thinking this has
>> >> something to do with contextlib, which it really doesn't (it's much more
>> >> closely related to threading.local()).
>> > This is my problem with using "Context" for this PEP. Although I can't
>> > keep up with all names being thrown around, it seems to me that in
>> > Python we already have a well-established meaning for "contexts" --
>> > context managers, and the protocols they implement as they participate
>> > in `with` statements. We have contextlib which reinforces this. What's
>> > being proposed in PEP 550 is so far removed from this concept that I
>> > think it's just going to cause confusion (well, it does in me anyway!).
>> While I understand the concern, I think context locals and contextlib
>> are more closely related than folks realise, as one of the main
>> problems that the PEP is aiming to solve is that with statements (and
>> hence context managers) *do not work as expected* when their body
>> includes "yield", "yield from" or "await" .
> If I write:
> def read_chunks(fn, chunk_size=8192):
> with open(fn, "rb") as f:
> while True:
> data = f.read(chunk_size)
> if not data:
> yield data
> The "with" statement here works fine even though its body includes a
> "yield" (and if there had been an added "await" things would probably
> not be different).
> The class of context managers you're talking about is in my experience a
> small minority (I've hardly ever used them myself, and I don't think I
> have ever written one).
I actually agree with this, as the vast majority of context managers
are about managing the state of frame locals, rather than messing
about with implicitly shared state. It's similar to the way that
thread locals are vastly outnumbered by ordinary frame locals.
That's part of what motivated my suggested distinction between
explicit context (such as your example here) and implicit context (the
trickier cases that PEP 550 aims to help handle).
> So I don't think the two concepts are as
> closely related as you seem to think.
Of the 12 examples in
https://www.python.org/dev/peps/pep-0343/#examples, two of them
related to manipulating the decimal thread local context, and a third
relates to manipulating a hidden "queue signals for later or process
them immediately?" flag, so the use cases that PEP 550 covers have
always been an intended subset of the use cases the PEP 343 covers.
It's just that the explicit use cases either already work sensibly in
the face of frame suspension (e.g. keeping a file open, since you're
still using it), or have other reasons why you wouldn't want to
suspend the frame after entering that particular context (e.g. if you
suspend a frame with a lock held, there's no real way for the
interpreter to guess whether that's intentional or not, so it has to
assume keeping it locked is intentional, and expect you to release it
explicitly if that's what you want)
And while PEP 550 doesn't handle the stream redirection case natively
(since it doesn't allow for suspend/resume callbacks the way PEP 525
does), it at least allows for the development of a context-aware
output stream wrapper API where:
* you replace the target stream globally with a context-aware wrapper
that delegates attribute access to a particular context local if
that's set and to the original stream otherwise
* you have a context manager that sets & reverts the context local
variable rather than manipulating the process global state directly
> That said, I also think "context" is the best term (barring
> "environment" perhaps) to describe what PEP 550 is talking about.
> Qualifying it ("logical", etc.) helps disambiguate
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
More information about the Python-Dev