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

Victor Stinner victor.stinner at gmail.com
Sat Sep 9 17:33:18 EDT 2017


I was able to find a real keyboard, so here is a more complete code:
---
class Noop:
    def __call__(self, *args, **kw):
        return self
    def __enter__(self, *args, **kw):
        return self
    def __exit__(self, *args):
        return
    def __repr__(self):
        return 'nope'
---

Example:
---
noop = Noop()
print(noop)
print(noop())
with noop() as nope:
    print(nope)
with noop as well:
    print(well)
---

Output:
---
nope
nope
nope
nope
---

IHMO the real question is if we need a Noop.nope() method?

Victor

2017-09-09 12:54 GMT-07:00 Victor Stinner <victor.stinner at gmail.com>:
> 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
>>
>


More information about the Python-Dev mailing list