[Python-Dev] PEP 559 - built-in noop()

[Victor Stinner]

I always wanted this feature (no kidding).

Would it be possible to add support for the context manager?

with noop(): ...

Maybe noop can be an instance of:

class Noop:
  def __enter__(self, *args, **kw): return self
  def __exit__(self, *args): pass
  def __call__(self, *args, **kw): return self

Victor

Le 9 sept. 2017 11:48 AM, "Barry Warsaw" <barry at python.org> a écrit :

> I couldn’t resist one more PEP from the Core sprint.  I won’t reveal where
> or how this one came to me.
>
> -Barry
>
> PEP: 559
> Title: Built-in noop()
> Author: Barry Warsaw <barry at python.org>
> Status: Draft
> Type: Standards Track
> Content-Type: text/x-rst
> Created: 2017-09-08
> Python-Version: 3.7
> Post-History: 2017-09-09
>
>
> 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
>
> The C built-in implementation is available as a pull request.
>
>
> 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``.
>
> 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.
>
>
> 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:
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> victor.stinner%40gmail.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20170909/4051b23b/attachment-0001.html>