On Sat, Sep 9, 2017 at 10:54 PM, Victor Stinner <victor.stin...@gmail.com>
wrote:
> 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
>
>
This worries me. Clearly, assuming a None-coercing noop, we must have:
noop(foo) is None
noop[foo] is None
noop * foo is None
foo * noop is None
noop + foo is None
foo + noop is None
noop - noop is None
...
noop / 0 is None
...
(noop == None) is None
which can all sort of be implicitly extrapolated to be in the PEP.
But how are you planning to implement:
(noop is None) is None
(obj in noop) is None
(noop in obj) is None
or
(None or noop) is None
(None and noop) is None
and finally:
foo(noop) is None
?
Sooner or later, someone will need all these features, and the PEP does not
seem to address the issue in any way.
-- Koos
> Victor
>
> Le 9 sept. 2017 11:48 AM, "Barry Warsaw" <ba...@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 <ba...@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@python.org
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe: https://mail.python.org/mailman/options/python-dev/victor.
>> stinner%40gmail.com
>>
>>
> _______________________________________________
> 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/
> k7hoven%40gmail.com
>
>
--
+ Koos Zevenhoven + http://twitter.com/k7hoven +
_______________________________________________
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/archive%40mail-archive.com
