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

[hniksic]

BPO	10049
Nosy	@birkenfeld, @rhettinger, @ncoghlan, @pitrou, @vstinner, @giampaolo, @hniksic, @merwok, @bitdancer, @voidspace, @durban, @albertz, @Jesse-Bakker
PRs	bpo-10049: Add a "no-op" (null) context manager to contextlib #4464
Files	fl nullcontext.patch

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/ncoghlan'
closed_at = <Date 2017-11-23.00:27:28.912>
created_at = <Date 2010-10-08.11:13:44.343>
labels = ['3.7', '3.8', 'type-feature', 'library']
title = 'Add a "no-op" (null) context manager to contextlib'
updated_at = <Date 2017-11-23.00:27:28.910>
user = 'https://github.com/hniksic'

bugs.python.org fields:

activity = <Date 2017-11-23.00:27:28.910>
actor = 'ncoghlan'
assignee = 'ncoghlan'
closed = True
closed_date = <Date 2017-11-23.00:27:28.912>
closer = 'ncoghlan'
components = ['Library (Lib)']
creation = <Date 2010-10-08.11:13:44.343>
creator = 'hniksic'
dependencies = []
files = ['19158', '19176']
hgrepos = []
issue_num = 10049
keywords = ['patch']
message_count = 43.0
messages = ['118181', '118183', '118184', '118185', '118186', '118187', '118189', '118190', '118193', '118194', '118195', '118196', '118200', '118274', '118406', '118409', '118448', '118450', '118453', '118599', '118616', '118626', '119514', '152909', '153046', '153049', '175656', '175662', '281177', '281180', '281195', '281200', '281215', '281234', '281264', '281556', '305951', '305952', '306001', '306002', '306266', '306770', '306771']
nosy_count = 18.0
nosy_names = ['georg.brandl', 'rhettinger', 'blais', 'ncoghlan', 'pitrou', 'vstinner', 'giampaolo.rodola', 'hniksic', 'eric.araujo', 'r.david.murray', 'michael.foord', 'daniel.urban', 'Albert.Zeyer', 'piotr.dobrogost', 'Alexander.Jones', 'DLitz', 'Martin Blais', 'jbakker']
pr_nums = ['4464']
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue10049'
versions = ['Python 3.7', 'Python 3.8']

[hniksic]

I find that I frequently need the "null" (no-op) context manager. For example, in code such as:

with transaction or contextlib.null():
    ...

Since there is no easy expression to create a null context manager, we must resort to workarounds, such as:

if transaction:
    with transaction:
        ... code ...
else:
    ... duplicated code ...

(with the usual options of moving the duplicated code to a function—but still.)

Or by creating ad-hoc null context managers with the help of contextlib.contextmanager:

if transaction is None:
    transaction = contextlib.contextmanager(lambda: iter([None])()
with transaction:
    ...

Adding a "null" context manager would be both practical and elegant. I have attached a patch for contextlib.py

[voidspace]

+1

Looks like a reasonable use case.

[voidspace]

Patch is missing tests and documentation.

[vstinner]

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" (NoOperation, NoOp, ...) or something else

[merwok]

I also find the Null/_null/null affair confusing.

[pitrou]

@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.

[hniksic]

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 generator definition, often repeated in different modules. This is markedly less elegant than just using contextlib.null() in an expression.

I'm not acquainted with the history of identity function requests, but note that the identity function can be defined as an expression, using simply lambda x: x. The equivalent expression that evaluates to a null context manager is markedly more convoluted, as shown in my report.

@Éric: The Null/_null/null distinction is an optimization that avoids creating new objects for something that is effectively a singleton. It would be perfectly reasonable to define contextlib.null as Antoine did, but, this being stdlib, I wanted the implementation to be as efficient as (reasonably) possible.

[pitrou]

@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 can use mymodule.null() where mymodule is a module gathering
common constructs of yours.

[ncoghlan]

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 bill.

The with statement isn't quite so forgiving. You need a genuine context manager in order to preserve the correct structure in the calling code. It isn't intuitively obvious how to do that easily. While not every 3-line function needs to be in the standard library, sometimes they're worth including to aid discoverability as much as anything else.

However, I don't see the point in making it a singleton and the name should include the word "context" so it doesn't becoming ambiguous when referenced without the module name (there's a reason we went with contextlib.contextmanager over contextlib.manager).

Something like:

class nullcontext():
    """No-op context manager, executes block without doing any additional processing.

Used as a standin if a particular block of code is only sometimes
used with a normal context manager:

      with optional_cm or nullcontext():
          # Perform operation, using the specified CM if one is given
    """
    def __enter__():
        pass
    def __exit__(*exc_info):
        pass

[hniksic]

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 "closing" constructor is also trivial to define, but it's there for convenience and to promote the use of with statement over try/finally boilerplate. The same goes here: you don't miss the null context manager when you don't have it; you invent other solutions. But when it's already available, it's an elegant pattern. In my experience, if they have to define it to get it, most people won't bother with the pattern and will retain less elegant solutions.

[ncoghlan]

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 docstring adjusted accordingly)

[ncoghlan]

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)