[Zope-dev] bug in mapply.py?

Tim Hicks tim@sitefusion.co.uk
Tue, 5 Nov 2002 16:24:55 -0000 (GMT)


Thanks for the reply Steve,

Steve Alexander said:
>
>> I must admit to not understanding why this should only break over
>> xmlrpc and not directly from Zope.  The problem appears to be that my
>> method is defined something like:
>>
>> def method(self, *args, **kw)
>
> mapply doesn't put things into **kw arguments of methods.

Yeah, that's what I understood to be the case.  However, coming in over
xmlrpc, I don't have any keyword arguments - I say that because that's
explicitly what I'm doing, but I'm not sure xmlrpc handles keyword args
anyway.  The **kw is just there for easier use when the method is called
directly from zope.

> I wanted this once for a product in Zope 3, looked deeply into mapply,
> and talked to Jim Fulton about it.
>
> IIRC, Jim said that mapply shouldn't put things into **kw arguments
> because it isn't at all explicit, and would end up implicitly putting in
>  a whole bunch of things that you generally wouldn't want in a lot of
> cases.
>
>
> Can you make up a simple python module to demonstrate your case, just
> using a method, and mapply?

I guess I could try, but I'm not convinced this is my problem at the moment.

> It may be that there's a way to achieve what you want, while still
> keeping things reasonably explicit.

>From what I can tell, the problem seems to be at line 58 (mapply.py):

names=c.co_varnames[1:c.co_argcount]

Given a call signature like:

def method(self, *args, **kw)

c.co_argcount == 1
c.co_varnames == ('self', 'args', 'kw')

Now, 'names' (the variable) becomes only 'self' (the string) on line 58. 
In this way, mapply.py seems to ignore the fact that I want my method to
accept an arbitrary number of arguments (line 69).

I don't know if there's a good reason for this, or whether I'm doing
things wrong.  I also don't know why this only crops up over xmlrpc, as I
presume mapply.py is used (in some way) from within zope as well.

Any ideas?

tim