On Fri, Feb 6, 2009 at 3:20 AM, Greg Ewing 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 proble
Greg Ewing 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 do its
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 t
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 "yiel
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 goin
> 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
Why is "call expr" a more enticing syntax than "yield *expr" ?
On Thu, Feb 5, 2009 at 9:31 PM, Greg Ewing 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 time for things li
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 g
On Thu, Feb 5, 2009 at 9:20 PM, Greg Ewing 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 put into
> the operat
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()
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 is
On Wed, Feb 4, 2009 at 11:48 AM, "Martin v. Löwis" 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 care much ab
On Wed, Feb 4, 2009 at 10:50 AM, Brett Cannon wrote:
> On Wed, Feb 4, 2009 at 10:43, Steven Bethard 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 C(object):
>> ... pass
>> .
On Wed, 4 Feb 2009 10:50:47 -0800, Brett Cannon wrote:
On Wed, Feb 4, 2009 at 10:43, Steven Bethard 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?
class C(object):
... pass
...
C._
> 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):
r
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
On Wed, Feb 4, 2009 at 10:43, Steven Bethard wrote:
> On Wed, Feb 4, 2009 at 10:25 AM, Brett Cannon wrote:
>> On Wed, Feb 4, 2009 at 05:35, Hrvoje Niksic wrote:
>>> Andrew Bennetts wrote:
A patch to add operator.caller(*args, **kwargs) may be a good idea. Your
example would then
On Wed, Feb 4, 2009 at 10:25 AM, Brett Cannon wrote:
> On Wed, Feb 4, 2009 at 05:35, Hrvoje Niksic 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 t
On Wed, Feb 4, 2009 at 05:35, Hrvoje Niksic 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
> operator.__ca
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
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
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 reasona
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, **kwa
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: x(),
24 matches
Mail list logo
