On 25 August 2017 at 20:28, Antoine Pitrou <solip...@pitrou.net> wrote: > On Fri, 25 Aug 2017 15:36:55 +1000 > Nick Coghlan <ncogh...@gmail.com> wrote: >> On 24 August 2017 at 23:52, Barry Warsaw <ba...@python.org> wrote: >> > Guido van Rossum wrote: >> >> On Tue, Aug 22, 2017 at 7:12 PM, Nathaniel Smith <n...@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: > break > 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 +1 Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
