(original) (raw)
On Wed, Nov 22, 2017 at 4:32 PM, Victor Stinner <victor.stinner@gmail.com> 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?
--Chris
https://github.com/python/cpython/commit/ 0784a2e5b174d2dbf7b144d480559e 650c5cf64c
https://bugs.python.org/issue10049
Victor
Unsubscribe: https://mail.python.org/
2017-09-09 21:54 GMT+02:00 Victor Stinner <victor.stinner@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@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@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
mailman/options/python-dev/ chris.jerdonek%40gmail.com