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 :

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" 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 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@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/victor.stinner%40gmail.co...

Previous discussion: https://bugs.python.org/issue10049 Issue closed as rejected. Victor 2017-09-09 14:33 GMT-07:00 Victor Stinner :

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 :

...

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" 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 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@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/victor.stinner%40gmail.co...

Aha, contextlib.nullcontext() was just added, cool! https://github.com/python/cpython/commit/0784a2e5b174d2dbf7b144d480559e650c5... https://bugs.python.org/issue10049 Victor 2017-09-09 21:54 GMT+02:00 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" 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 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@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/victor.stinner%40gmail.co...

On 23 November 2017 at 19:42, Chris Jerdonek wrote:

On Wed, Nov 22, 2017 at 4:32 PM, Victor Stinner wrote:

...

Aha, contextlib.nullcontext() was just added, cool!

So is this equivalent to--

@contextmanager def yielding(x): yield x

I thought we were against adding one-line functions?

There's a lot of runtime complexity hiding behind that "@contextmanager" line, so I'm open to `contextlib` additions that make it possible for sufficiently common patterns to avoid it. (The explicit class based nullcontext() implementation is 7 lines, the same as contextlib.closing()) After 7+ years, I'm happy that this one comes up often enough to be worth a more obvious standard library level answer than we'd previously offered. https://bugs.python.org/issue10049#msg281556 captures the point where I really started changing my mind. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

On 24 November 2017 at 01:49, Barry Warsaw wrote:

On Nov 22, 2017, at 19:32, Victor Stinner 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@gmail.com | Brisbane, Australia

On Sep 9, 2017, at 15:12, Guido van Rossum wrote:

I can't tell whether this was meant seriously, but I don't think it's worth it. People can easily write their own dummy function and give it any damn semantics they want. Let's reject the PEP.

Alrighty then! (Yes, it was serious, but I claim post-sprint euphoria/delirium). -Barry

On Mon, Sep 11, 2017 at 7:29 AM, Koos Zevenhoven wrote:

On Sun, Sep 10, 2017 at 8:21 PM, Barry Warsaw wrote:

...

On Sep 9, 2017, at 15:12, Guido van Rossum wrote:

...

I can't tell whether this was meant seriously, but I don't think it's worth it. People can easily write their own dummy function and give it any damn semantics they want. Let's reject the PEP.

Alrighty then! (Yes, it was serious, but I claim post-sprint euphoria/delirium).

Just for future reference, here's a slightly more serious comment:

I think the "pass" statement wasn't mentioned yet, but clearly noop() would be duplication of functionality. So maybe the closest thing without duplication would be to make "pass" an expression which evaluates to a no-op function, but which the compiler could perhaps optimize away if it's a statement by itself, or is a builtin.

As a language change, definitely not. But I like this idea for PYTHONBREAKPOINT. You set it to the name of a function, or to "pass" if you want nothing to be done. It's a special case that can't possibly conflict with normal usage. ChrisA

On Mon, Sep 11, 2017 at 11:03 AM, Barry Warsaw wrote:

On Sep 10, 2017, at 14:39, Chris Angelico wrote:

...

As a language change, definitely not. But I like this idea for PYTHONBREAKPOINT. You set it to the name of a function, or to "pass" if you want nothing to be done. It's a special case that can't possibly conflict with normal usage.

I have working code for `PYTHONBREAKPOINT=0` and `PYTHONBREAKPOINT= ` (i.e. the empty string as given by getenv()) meaning “disable”. I don’t think we also need `PYTHONBREAKPOINT=pass`.

Blank is the other one that I would stumble to. Works for me. ChrisA