Guido van Rossum wrote:
Why is call expr a more enticing syntax than yield *expr ?
I was thinking it would read better when you're
using generators as lightweight threads, and you
want the one-level-deep nature of generators to
be hidden as much as possible.
The fact that yielding is going
Greg Ewing writes:
The fact that yielding is going on is not of
interest in that situation -- it's just an
implementation detail. What you really want to
express is calling another function, but without
losing your status of coroutine-ness.
But doesn't yield in the sense of yield the
Stephen J. Turnbull wrote:
Greg Ewing writes:
The fact that yielding is going on is not of
interest in that situation
But doesn't yield in the sense of yield the right of way mean
exactly that?
I've no problem with using 'yield' when actually
giving up control. But the code making the
Greg Ewing greg.ewing at canterbury.ac.nz writes:
I've no problem with using 'yield' when actually
giving up control. But the code making the call doesn't
think of itself as yielding. The called code may
want to yield, but the caller doesn't care about
that. It just wants to make the callee
On Fri, Feb 6, 2009 at 3:20 AM, Greg Ewing greg.ew...@canterbury.ac.nz wrote:
Stephen J. Turnbull wrote:
Greg Ewing writes:
The fact that yielding is going on is not of
interest in that situation
But doesn't yield in the sense of yield the right of way mean
exactly that?
I've no
Guido van Rossum wrote:
def call(o, *args, **kwds):
return o(*args, **kwds)
which would make call a synonym for apply (and would also provide for
the first definition as a special case). However, with that API, it
isn't so easy anymore to pass the same arguments to all callables
(unless it
Hrvoje Niksic wrote:
Is there a reason why the operator module doesn't have an operator.call
function?
I've been thinking about proposing an enhancement
concerning generators that would entail making
call a reserved word, so I'd be a little
disappointed if this name were used.
Maybe apply()
On Thu, Feb 5, 2009 at 9:20 PM, Greg Ewing greg.ew...@canterbury.ac.nz wrote:
I've been thinking about proposing an enhancement
concerning generators that would entail making
call a reserved word, so I'd be a little
disappointed if this name were used.
Maybe apply() could be reinstated and
Guido van Rossum wrote:
What's so special about your proposal that requires a new keyword?
I was thinking about the proposals that are made
from time to time for things like
yield *foo
to yield all the items from a sub-generator. I was
also thinking about what could be done to make
using
Why is call expr a more enticing syntax than yield *expr ?
On Thu, Feb 5, 2009 at 9:31 PM, Greg Ewing greg.ew...@canterbury.ac.nz wrote:
Guido van Rossum wrote:
What's so special about your proposal that requires a new keyword?
I was thinking about the proposals that are made
from time to
I came up with the idea of a new statement
call expr
I don't think your ideas should stop us from doing the right
thing right now, i.e. add operator.call (for symmetry with
everything else that is in the operator module).
Whether a call keyword gets added to Python remains to be seen;
I
Is there a reason why the operator module doesn't have an operator.call
function? It would seem logical to be able to write:
map(operator.call, lst)
which calls each object in lst, just like map(operator.neg, lst) negates
every object. Of course, operator.call is equivalent to lambda x:
Hrvoje Niksic wrote:
Is there a reason why the operator module doesn't have an operator.call
function?
My guess is that it was left out because it would have been redundant
given the existence of apply() in 2.x.
That argument no longer holds in 3.x of course, so operator.call may be
a
Andrew Bennetts wrote:
A patch to add operator.caller(*args, **kwargs) may be a good idea. Your
example would then be:
map(operator.caller(), lst)
Regarding the name, note that I proposed operator.call (and
operator.__call__) because it corresponds to the __call__ special
method, which
Nick Coghlan wrote:
I'm somewhere between -0 and +0 though (-0 due to the lack of concrete
use cases, +0 because the improved consistency is appealing)
The operator module is one of the rare cases in python where consistency
is valued more than concrete use cases. But, for what it's worth, I
Hrvoje Niksic wrote:
Is there a reason why the operator module doesn't have an operator.call
function?
Python 2.6 adds operator.methodcaller. So you could use
operator.methodcaller('__call__'), but that's not really any better than
lambda x: x().
A patch to add operator.caller(*args,
On Wed, Feb 4, 2009 at 05:35, Hrvoje Niksic hrvoje.nik...@avl.com wrote:
Andrew Bennetts wrote:
A patch to add operator.caller(*args, **kwargs) may be a good idea. Your
example would then be:
map(operator.caller(), lst)
Regarding the name, note that I proposed operator.call (and
On Wed, Feb 4, 2009 at 10:25 AM, Brett Cannon br...@python.org wrote:
On Wed, Feb 4, 2009 at 05:35, Hrvoje Niksic hrvoje.nik...@avl.com wrote:
Andrew Bennetts wrote:
A patch to add operator.caller(*args, **kwargs) may be a good idea. Your
example would then be:
map(operator.caller(),
On Wed, Feb 4, 2009 at 10:43, Steven Bethard steven.beth...@gmail.com wrote:
On Wed, Feb 4, 2009 at 10:25 AM, Brett Cannon br...@python.org wrote:
On Wed, Feb 4, 2009 at 05:35, Hrvoje Niksic hrvoje.nik...@avl.com wrote:
Andrew Bennetts wrote:
A patch to add operator.caller(*args, **kwargs)
I believe the omission of call from the operator module is an
oversight, perhaps caused by the existence (when the operator module
was created) of apply. Since apply has been removed from 3.0, we
should add operator.call (with the same signature) back. It should be
a straightforward wrapper around
If there is interest in this and no reason why it shouldn't be done, I
can write up an issue in the tracker and provide a patch.
I think there is a tricky design choice to make wrt. argument passing.
IIUC, you don't care much about arguments, so you could probably live
with
def call(o):
On Wed, 4 Feb 2009 10:50:47 -0800, Brett Cannon br...@python.org wrote:
On Wed, Feb 4, 2009 at 10:43, Steven Bethard steven.beth...@gmail.com wrote:
[snip]
Not sure I follow you here. It's not the __init__ that allows you to
do ``x()``, it's the fact that the class declares a __call__, right?
On Wed, Feb 4, 2009 at 10:50 AM, Brett Cannon br...@python.org wrote:
On Wed, Feb 4, 2009 at 10:43, Steven Bethard steven.beth...@gmail.com wrote:
Not sure I follow you here. It's not the __init__ that allows you to
do ``x()``, it's the fact that the class declares a __call__, right?
class
On Wed, Feb 4, 2009 at 11:48 AM, Martin v. Löwis mar...@v.loewis.de wrote:
If there is interest in this and no reason why it shouldn't be done, I
can write up an issue in the tracker and provide a patch.
I think there is a tricky design choice to make wrt. argument passing.
IIUC, you don't
24 matches
Mail list logo
