[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)

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

Change by Jesse Bakker : -- nosy: +Jesse Bakker ___ Python tracker ___ ___

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

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

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

Change by Jesse Bakker : -- versions: +Python 3.8 -Python 3.2 ___ Python tracker ___

[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. -- ___

[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

[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

[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

[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

[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

[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

[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:

[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

[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

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

Changes by Piotr Dobrogost p...@bugs.python.dobrogost.net: -- nosy: +piotr.dobrogost ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10049 ___ ___

[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

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

Nick Coghlan ncogh...@gmail.com 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

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

Alexander Jones aj.d...@gmail.com added the comment: That's very reassuring. Thanks, Nick! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10049 ___

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

Alexander Jones aj.d...@gmail.com 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

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

Nick Coghlan ncogh...@gmail.com 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

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

Georg Brandl ge...@python.org 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 rep...@bugs.python.org

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

Raymond Hettinger rhettin...@users.sourceforge.net 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

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

Nick Coghlan ncogh...@gmail.com 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

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

Hrvoje Nikšić hnik...@gmail.com 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

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

R. David Murray rdmur...@bitdance.com added the comment: Unless Nick has further feedback I think you've done all you need to, thanks. -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10049

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

Giampaolo Rodola' g.rod...@gmail.com 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

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

R. David Murray rdmur...@bitdance.com 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 rep...@bugs.python.org

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

Raymond Hettinger rhettin...@users.sourceforge.net 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

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

Hrvoje Nikšić hnik...@gmail.com 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.

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

Changes by Nick Coghlan ncogh...@gmail.com: -- assignee: - ncoghlan ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10049 ___ ___ Python-bugs-list

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

Changes by STINNER Victor victor.stin...@haypocalc.com: -- title: Add the null context manager to contextlib - Add a no-op (null) context manager to contextlib ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10049

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

Michael Foord mich...@voidspace.org.uk added the comment: +1 Looks like a reasonable use case. -- nosy: +michael.foord, ncoghlan ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10049 ___

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

Michael Foord mich...@voidspace.org.uk added the comment: Patch is missing tests and documentation. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10049 ___

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

STINNER Victor victor.stin...@haypocalc.com 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

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

Éric Araujo mer...@netwok.org added the comment: I also find the Null/_null/null affair confusing. -- nosy: +eric.araujo stage: - patch review versions: +Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10049

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

Antoine Pitrou pit...@free.fr 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

Hrvoje Nikšić hnik...@gmail.com 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

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

Antoine Pitrou pit...@free.fr 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

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

Nick Coghlan ncogh...@gmail.com 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

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

Hrvoje Nikšić hnik...@gmail.com 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

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

Hrvoje Nikšić hnik...@gmail.com 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

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

Changes by Daniel Urban urban.dani...@gmail.com: -- nosy: +durban ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10049 ___ ___ Python-bugs-list