[issue10049] Add a "no-op" (null) context manager to contextlib

Nick Coghlan added the comment: Thanks to Jesse Bakker for the PR implementing this for 3.7! -- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.7 ___ Python tracker

[issue10049] Add a "no-op" (null) context manager to contextlib

Nick Coghlan added the comment: New changeset 0784a2e5b174d2dbf7b144d480559e650c5cf64c by Nick Coghlan (Jesse-Bakker) in branch 'master': bpo-10049: Add a "no-op" (null) context manager to contextlib (GH-4464) https://github.com/python/cpython/commit/0784a2e5b174d2dbf7b144d480559e650c5cf64c

[issue10049] Add a "no-op" (null) context manager to contextlib

Change by Jesse Bakker : -- nosy: +Jesse Bakker ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.p

[issue10049] Add a "no-op" (null) context manager to contextlib

Change by Jesse Bakker : -- pull_requests: +4397 stage: needs patch -> patch review ___ Python tracker ___ ___ Python-bugs-list maili

[issue10049] Add a "no-op" (null) context manager to contextlib

Change by Jesse Bakker : -- versions: +Python 3.8 -Python 3.2 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue10049] Add a "no-op" (null) context manager to contextlib

Hrvoje Nikšić added the comment: I am of course willing to sign the CLA (please send further instructions via email), although I don't know how useful my original patch is, given that it caches the null context manager. -- ___ Python tracker

[issue10049] Add a "no-op" (null) context manager to contextlib

Nick Coghlan added the comment: Reverting to "Needs patch", as the currently attached patch is for the "No behaviour" variant that always returns None from __enter__(). (hniksic, would you still be willing to sign the Python CLA? If so, then your patch could be used as the basis for an update

[issue10049] Add a "no-op" (null) context manager to contextlib

Nick Coghlan added the comment: Reopening this based on several years of additional experience with context managers since I wrote https://bugs.python.org/issue10049#msg119514 when originally closing it. The version I'm now interested in adding is the one from https://bugs.python.org/issue10

[issue10049] Add a "no-op" (null) context manager to contextlib (Rejected: use contextlib.ExitStack())

Hrvoje Nikšić added the comment: For what it's worth, we are still using our own null context manager function in critical code. We tend to avoid contextlib.ExitStack() for two reasons: 1) it is not immediately clear from looking at the code what ExitStack() means. (Unlike the "contextmanager

[issue10049] Add a "no-op" (null) context manager to contextlib (Rejected: use contextlib.ExitStack())

Albert Zeyer added the comment: Note that this indeed seems confusing. I just found this thread by search for a null context manager. Because I found that in TensorFlow they introduced _NullContextmanager in their code and I wondered that this is not provided by the Python stdlib. --

[issue10049] Add a "no-op" (null) context manager to contextlib (Rejected: use contextlib.ExitStack())

Nick Coghlan added the comment: It turns out that there's a variant on the "null context manager" idea that may *not* be redundant with ExitStack(), and hence could potentially counter the current rationale for not adding one. Specifically, it relates to context managers like click.progressbar

[issue10049] Add a "no-op" (null) context manager to contextlib (Rejected: use contextlib.ExitStack())

Nick Coghlan added the comment: Unfortunately, the redundancy doesn't buy enough to justify the permanent documentation and style guide cost of providing two ways to do exactly the same thing. -- ___ Python tracker

[issue10049] Add a "no-op" (null) context manager to contextlib (Rejected: use contextlib.ExitStack())

Martin Blais added the comment: Well that just echoes exactly what I originally thought, but somebody else said it was not needed because ExitStack already exists and could be used for that purpose. If this were at work and/or it were all just to me, I'd just implement a brand new nullcontext

[issue10049] Add a "no-op" (null) context manager to contextlib (Rejected: use contextlib.ExitStack())

Nick Coghlan added the comment: No, it wouldn't, as ExitStack() does far more than merely implement a null context. It would be like adding "nulliterable = ()" as a builtin, rather than just telling people "If you need a null iterable, use an empty tuple". --

[issue10049] Add a "no-op" (null) context manager to contextlib (Rejected: use contextlib.ExitStack())

Martin Blais added the comment: Adding nullcontext = ExitStack in the source file would solve this problem in a single line of code. -- nosy: +blais ___ Python tracker ___ _

[issue10049] Add a "no-op" (null) context manager to contextlib (Rejected: use contextlib.ExitStack())

Nick Coghlan added the comment: The problem Martin is referring to is the SEO one, which is that the top link when searching for either "null context manager python" or "no-op context manager python" is this thread, rather than the "Use ExitStack for that" recipe in the docs: https://docs.pyt

[issue10049] Add a "no-op" (null) context manager to contextlib

Giampaolo Rodola' added the comment: ExitStack() already covers the "null ctx mgr" use case described in the first message. Original example: with transaction or contextlib.null(): ... By using ExitStack: with transaction or ExitStack(): ... You can push this further and do this,

[issue10049] Add a "no-op" (null) context manager to contextlib

Martin Blais added the comment: I've been looking for this today; I would have used it. Instead of an obvious (and explicit) null context manager, I had to read through this entire thread to eventually find out that I can use something called ExitStack(), which is designed for another use case

[issue10049] Add a "no-op" (null) context manager to contextlib

Changes by Piotr Dobrogost : -- nosy: +piotr.dobrogost ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://

[issue10049] Add a "no-op" (null) context manager to contextlib

Nick Coghlan added the comment: No, an empty ExitStack() instance already works fine as a no-op context manager in 3.3: http://docs.python.org/3/library/contextlib#simplifying-support-for-single-optional-context-managers We're not going to add a dedicated one under a different name. -

[issue10049] Add a "no-op" (null) context manager to contextlib

Dwayne Litzenberger added the comment: After seeing a context manager named like "TempfileIfNeeded(..., cond)", whole sole purpose is to handle the conditional case, I'm firmly +1 on this proposal. It's much easier to just read "with Tempfile() if cond else nullcontext():" than to read through

[issue10049] Add a "no-op" (null) context manager to contextlib

Alexander Jones added the comment: That's very reassuring. Thanks, Nick! -- ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue10049] Add a "no-op" (null) context manager to contextlib

Nick Coghlan added the comment: FWIW, it's likely I'll be adding contextlib.ContextStack (see [1]) for 3.3. While it's far from the primary use case, that API also serves as a "no-op" context manager (if you never register any contexts or callbacks, the __exit__ impl does nothing). [1] http

[issue10049] Add a "no-op" (null) context manager to contextlib

Alexander Jones added the comment: Not having this as a standard idiom makes it very tempting to just do copy-paste coding as in hniksic's example. Who likes to invent their own library for generic language-supporting idioms? What about an alternative of giving NoneType empty enter and exit m

[issue10049] Add a "no-op" (null) context manager to contextlib

Nick Coghlan added the comment: I find Raymond's perspective persuasive in this case. Feel free to post either the original idea or my later variant as an ASPN cookbook recipe. (you could actually combine the two, and use NullContext as an implementation detail of an optional_cm() function)

[issue10049] Add a "no-op" (null) context manager to contextlib

Raymond Hettinger added the comment: > To me, this is more a matter of conceptual completeness > than one of practical utility ... Nick, you don't seem to be truly sold on the need. I'm -1 on adding this. It's basically cruft. If it were published as an ASPN recipe, its uptake would be nearl

[issue10049] Add a "no-op" (null) context manager to contextlib

Georg Brandl added the comment: I like your latest suggestion, except for the name. Given that we also have the (quite generic) "closing", what about just "optional"? -- nosy: +georg.brandl ___ Python tracker __

[issue10049] Add a "no-op" (null) context manager to contextlib

Nick Coghlan added the comment: To me, this is more a matter of conceptual completeness than one of practical utility (ala fractions.Fraction). That said, I *have* personally encountered the "I only sometimes want to wrap this code in a CM" situation, so it isn't completely impractical, eithe

[issue10049] Add a "no-op" (null) context manager to contextlib

Raymond Hettinger added the comment: Are you sure that this is useful enough to warrant inclusion in the standard lib? I don't know of anyone else who has used the same idiom. It seems crufty to me -- something that adds weight (mental burden and maintenance effort) without adding much valu

[issue10049] Add a "no-op" (null) context manager to contextlib

R. David Murray added the comment: Because hardcoding a particular condition into a context manager is less flexible? (I'm +0 on this thing myself, by the way.) -- ___ Python tracker

[issue10049] Add a "no-op" (null) context manager to contextlib

Giampaolo Rodola' added the comment: I'm with Antoine. Why not just do this in the context function itself? I think it's more explicit and easier than reading the doc to figure out what nullcontext is supposed to do: from contextlib import contextmanager CONDITION = False @contextmanager de

[issue10049] Add a "no-op" (null) context manager to contextlib

R. David Murray added the comment: Unless Nick has further feedback I think you've done all you need to, thanks. -- nosy: +r.david.murray ___ Python tracker ___

[issue10049] Add a "no-op" (null) context manager to contextlib

Hrvoje Nikšić added the comment: Is there anything else I need to do to have the patch reviewed and applied? I am in no hurry since we're still using 2.x, I'd just like to know if more needs to be done on my part to move the issue forward. My last Python patch was accepted quite some years a

[issue10049] Add a "no-op" (null) context manager to contextlib

Changes by Nick Coghlan : -- assignee: -> ncoghlan ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail

[issue10049] Add a "no-op" (null) context manager to contextlib

Hrvoje Nikšić added the comment: Here is a more complete patch that includes input from Nick, as well as the patch to test_contextlib.py and the documentation. For now I've retained the function-returning-singleton approach for consistency and future extensibility. -- keywords: +patc

[issue10049] Add a "no-op" (null) context manager to contextlib

Changes by Daniel Urban : -- nosy: +durban ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.o

[issue10049] Add a "no-op" (null) context manager to contextlib

Hrvoje Nikšić added the comment: I considered using a variable, but I went with the factory function for two reasons: consistency with the rest of contextlib, and equivalence to the contextmanager-based implementation. Another reason is that it leaves the option of adding optional parameters

[issue10049] Add a "no-op" (null) context manager to contextlib

Nick Coghlan added the comment: If you can supply a full patch before the end of the month, we should be able to get this in for 3.2beta1 (currently scheduled for 31 October) -- ___ Python tracker ___

[issue10049] Add a "no-op" (null) context manager to contextlib

Nick Coghlan added the comment: Actually, the singleton idea isn't a bad one, but I'd go one step further and skip the factory function as well. So change that to be: class NullContext(): ... # as per nullcontext in my last message nullcontext = NullContext() (with the example in the docs

[issue10049] Add a "no-op" (null) context manager to contextlib

Hrvoje Nikšić added the comment: That is what we are using now, but I think a contextlib.null() would be useful to others, i.e. that its use is a useful idiom to adopt. Specifically I would like to discourage the "duplicated code" idiom from the report, which I've seen all too often. The "c

[issue10049] Add a "no-op" (null) context manager to contextlib

Nick Coghlan added the comment: The difference here is the one pointed out in the original post: for a function, you usually only care about having a value, so if you don't want to call it, you can just swap in a None value instead. If you need an actual callable, then "lambda:None" fits the

[issue10049] Add a "no-op" (null) context manager to contextlib

Antoine Pitrou added the comment: > @Antoine: it is true that a null context manager can be easily > defined, but it does requires a separate generator definition, often > repeated in different modules. This is markedly less elegant than > just using contextlib.null() in an expression. But you

[issue10049] Add a "no-op" (null) context manager to contextlib

Hrvoje Nikšić added the comment: Thank you for your comments. @Michael: I will of course write tests and documentation if there is indication that the feature will be accepted for stdlib. @Antoine: it is true that a null context manager can be easily defined, but it does requires a separate

[issue10049] Add a "no-op" (null) context manager to contextlib

Antoine Pitrou added the comment: @contextlib.contextmanager def null(): yield Do we really need to add this to the stdlib? Previous proposals to add an "identity function" or "no-op function" have always be refused. This one seems even less useful. -- nosy: +pitrou _

[issue10049] Add a "no-op" (null) context manager to contextlib

Éric Araujo added the comment: I also find the Null/_null/null affair confusing. -- nosy: +eric.araujo stage: -> patch review versions: +Python 3.2 ___ Python tracker ___ _

[issue10049] Add a "no-op" (null) context manager to contextlib

STINNER Victor added the comment: About your patch: - __enter__() might return self instead of None... i don't really know which choice is better. "with Null() as x:" works in both cases - __exit__() has no result value, "pass" is enough - I don't like "Null" name, I prefer "Noop" (NoOperati

[issue10049] Add a "no-op" (null) context manager to contextlib

Michael Foord added the comment: Patch is missing tests and documentation. -- ___ Python tracker ___ ___ Python-bugs-list mailing lis

[issue10049] Add a "no-op" (null) context manager to contextlib

Michael Foord added the comment: +1 Looks like a reasonable use case. -- nosy: +michael.foord, ncoghlan ___ Python tracker ___ ___ P

[issue10049] Add a "no-op" (null) context manager to contextlib

Changes by STINNER Victor : -- title: Add the null context manager to contextlib -> Add a "no-op" (null) context manager to contextlib ___ Python tracker ___ ___