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
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?
from functools import wraps
def noop(func):
@wraps(func)
def wrapper(*args, **kws):
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
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?
--Chris
>
>
Aha, contextlib.nullcontext() was just added, cool!
https://github.com/python/cpython/commit/0784a2e5b174d2dbf7b144d480559e650c5cf64c
https://bugs.python.org/issue10049
Victor
2017-09-09 21:54 GMT+02:00 Victor Stinner :
> I always wanted this feature (no kidding).
>
>
On Mon, Sep 11, 2017 at 07:39:07AM +1000, 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
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
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
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
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
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
Don't we already have the mock module for that ? A mowk works as a noop,
will be ok with being used as a context manager and allow chaining...
Either way, what would a noop function really give you compared to
lambda *a, **b: None ?
A be bit shorter to write. Maybe faster to run. But do you use
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.
On Sat, Sep 9, 2017 at 11:46 AM, Barry Warsaw wrote:
> I couldn’t resist one more
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):
>
On Sat, Sep 9, 2017 at 10:54 PM, Victor Stinner
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,
On Sat, Sep 09, 2017 at 02:33:18PM -0700, Victor Stinner
wrote:
> 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):
>
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'
---
On Sat, 9 Sep 2017 11:46:30 -0700
Barry Warsaw wrote:
>
> 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
09.09.17 21:46, Barry Warsaw пише:
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
Are there other use cases? PEP 553 still is not approved, and you could
use
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
I don't think the rationale justifies an entire builtin. You could just use
"PYTHONBREAKPOINT=int" to disable, or support "PYTHONBREAKPOINT=0" as I
think someone else suggested. I personally can't remember the last time I
needed a noop() function. I've more often needed an identity() function,
and
On 2017-09-09 19:46, Barry Warsaw wrote:
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:
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
23 matches
Mail list logo