2017-09-08 19:12:51 -04:00
|
|
|
|
PEP: 559
|
|
|
|
|
Title: Built-in noop()
|
|
|
|
|
Author: Barry Warsaw <barry@python.org>
|
2017-09-10 13:18:53 -04:00
|
|
|
|
Status: Rejected
|
2017-09-08 19:12:51 -04:00
|
|
|
|
Type: Standards Track
|
|
|
|
|
Content-Type: text/x-rst
|
|
|
|
|
Created: 2017-09-08
|
|
|
|
|
Python-Version: 3.7
|
2017-09-09 14:42:08 -04:00
|
|
|
|
Post-History: 2017-09-09
|
2017-09-10 14:29:01 -04:00
|
|
|
|
Resolution: https://mail.python.org/pipermail/python-dev/2017-September/149438.html
|
2017-09-08 19:12:51 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Abstract
|
|
|
|
|
========
|
|
|
|
|
|
|
|
|
|
This PEP proposes adding a new built-in function called ``noop()`` which does
|
|
|
|
|
nothing but return ``None``.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Rationale
|
|
|
|
|
=========
|
|
|
|
|
|
|
|
|
|
It is trivial to implement a no-op function in Python. It's so easy in fact
|
|
|
|
|
that many people do it many times over and over again. It would be useful in
|
|
|
|
|
many cases to have a common built-in function that does nothing.
|
|
|
|
|
|
|
|
|
|
One use case would be for PEP 553, where you could set the breakpoint
|
|
|
|
|
environment variable to the following in order to effectively disable it::
|
|
|
|
|
|
|
|
|
|
$ setenv PYTHONBREAKPOINT=noop
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Implementation
|
|
|
|
|
==============
|
|
|
|
|
|
|
|
|
|
The Python equivalent of the ``noop()`` function is exactly::
|
|
|
|
|
|
|
|
|
|
def noop(*args, **kws):
|
|
|
|
|
return None
|
|
|
|
|
|
2017-09-10 13:02:56 -04:00
|
|
|
|
The C built-in implementation is available as a pull request [1]_.
|
2017-09-08 19:12:51 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Rejected alternatives
|
|
|
|
|
=====================
|
|
|
|
|
|
|
|
|
|
``noop()`` returns something
|
|
|
|
|
----------------------------
|
|
|
|
|
|
|
|
|
|
YAGNI.
|
|
|
|
|
|
|
|
|
|
This is rejected because it complicates the semantics. For example, if you
|
|
|
|
|
always return both ``*args`` and ``**kws``, what do you return when none of
|
|
|
|
|
those are given? Returning a tuple of ``((), {})`` is kind of ugly, but
|
|
|
|
|
provides consistency. But you might also want to just return ``None`` since
|
|
|
|
|
that's also conceptually what the function was passed.
|
|
|
|
|
|
|
|
|
|
Or, what if you pass in exactly one positional argument, e.g. ``noop(7)``. Do
|
|
|
|
|
you return ``7`` or ``((7,), {})``? And so on.
|
|
|
|
|
|
|
|
|
|
The author claims that you won't ever need the return value of ``noop()`` so
|
|
|
|
|
it will always return ``None``.
|
|
|
|
|
|
2017-09-09 14:41:41 -04:00
|
|
|
|
Coghlin's Dialogs (edited for formatting):
|
|
|
|
|
|
|
|
|
|
My counterargument to this would be ``map(noop, iterable)``,
|
|
|
|
|
``sorted(iterable, key=noop)``, etc. (``filter``, ``max``, and
|
|
|
|
|
``min`` all accept callables that accept a single argument, as do
|
|
|
|
|
many of the itertools operations).
|
|
|
|
|
|
|
|
|
|
Making ``noop()`` a useful default function in those cases just
|
|
|
|
|
needs the definition to be::
|
|
|
|
|
|
|
|
|
|
def noop(*args, **kwds):
|
|
|
|
|
return args[0] if args else None
|
|
|
|
|
|
|
|
|
|
The counterargument to the counterargument is that using ``None``
|
|
|
|
|
as the default in all these cases is going to be faster, since it
|
|
|
|
|
lets the algorithm skip the callback entirely, rather than calling
|
|
|
|
|
it and having it do nothing useful.
|
|
|
|
|
|
2017-09-08 19:12:51 -04:00
|
|
|
|
|
2017-09-10 13:02:56 -04:00
|
|
|
|
References
|
|
|
|
|
==========
|
|
|
|
|
|
|
|
|
|
.. [1] https://github.com/python/cpython/pull/3480
|
|
|
|
|
|
|
|
|
|
|
2017-09-08 19:12:51 -04:00
|
|
|
|
Copyright
|
|
|
|
|
=========
|
|
|
|
|
|
|
|
|
|
This document has been placed in the public domain.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
..
|
|
|
|
|
Local Variables:
|
|
|
|
|
mode: indented-text
|
|
|
|
|
indent-tabs-mode: nil
|
|
|
|
|
sentence-end-double-space: t
|
|
|
|
|
fill-column: 70
|
|
|
|
|
coding: utf-8
|
|
|
|
|
End:
|