[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