namespaces and eval

[Arnaud Delobelle]

dave.g1234 at gmail.com writes:

> On May 16, 2:47 pm, "bruno.desthuilli... at gmail.com"
> <bruno.desthuilli... at gmail.com> wrote:
>> On 16 mai, 23:23, dave.g1... at gmail.com wrote:
>>
>> > Thanks for the responses.  I'm well aware that the function can be
>> > passed in the parameters, passing in the functino as an arg defeats
>> > the purpose of what I'm going after.
>>
>> Why so ?
>> > @ Arnaud - Nice. I'm not sure what the performance of mine vs. yours,
>> > but a perfunctory glance looks like we're doing the close to the same
>> > thing.  Maybe one advanage to doing it wrap(x).foo().... is that you
>> > can pass in other parameters to foo.
>>
>> I may be wrong (if so please pardon my lack of intelligence and/or
>> provide a couple use case), but it looks like you're trying to
>> reinvent partial application.
>>
>> from functools import partial
>> def foo(x, y):
>>   return x + y
>>
>> pfoo = partial(foo, 2)
>> print pfoo(42)
>>
>> Don't know if this helps...
>
> Ok, so that solves the issue of the aforementioned compose function.
> We could do compose( partialfoo,....) ) etc (although I might say I
> prefer wrap(x).foo(23).foo(16 ..etc )  The original idea was to
> provide wrapper around an object that lets you call abritrary
> functions on that object with it as a parameter - i.e., as if it were
> a method in a class.  The partial function was only a component of the
> code I posted earlier. Or am I missing something you're saying?

Ok so you want to do

    wrap(x).foo(42).bar('spam')...

What is the advantage over

    foo(x, 42)
    bar(x, 'spam')
    ...

?

-- 
Arnaud