[Python-Dev] PEP 559 - built-in noop()
Nick Coghlan
ncoghlan at gmail.com
Thu Nov 23 20:17:43 EST 2017
On 24 November 2017 at 01:49, Barry Warsaw <barry at python.org> wrote:
> On Nov 22, 2017, at 19:32, Victor Stinner <victor.stinner at gmail.com>
> wrote:
> >
> > Aha, contextlib.nullcontext() was just added, cool!
>
> So, if I rewrite PEP 559 in terms of decorators it won’t get rejected?
>
The conceptual delta between knowing how to call "noop()" and how to write
"def noop(): pass" is just a *teensy* bit smaller than that between knowing
how to use:
with nullcontext(value) as var:
...
and how to write:
@contextlib.contextmanager
def nullcontext(enter_result):
yield enter_result
or:
class nullcontext(object):
def __init__(self, enter_result):
self.enter_result = enter_result
def __enter__(self):
return self.enter_result
def __exit__(self, *args):
pass
So the deciding line for me was "Should people need to know how to write
their own context managers in order to have access to a null context
manager?", and I eventually decided the right answer was "No", since the
context management protocol is actually reasonably tricky conceptually, and
even the simplest version still requires knowing how to use decorators and
generators (as well as knowing which specific decorator to use).
The conceptual step between calling and writing functions is much smaller,
and defining your own re-usable functions is a more fundamental Python
skill than defining your own context managers.
And while I assume you were mostly joking, the idea of a
"@functools.stub_call(result=None)" decorator to temporarily replace an
otherwise expensive function call could be a genuinely interesting
primitive. `unittest.mock` and other testing libraries already have a bunch
of tools along those lines, so the principle at work there would be pattern
extraction based on things people already do for themselves.
Cheers,
Nick.
--
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20171124/e668e5d6/attachment.html>
More information about the Python-Dev
mailing list