Hi all, I've been trying to track down the problem outlined here *: http://zope.nipltd.com/public/lists/zope-archive.nsf/ByKey/B9323F6D666D3D5C I got a traceback (see below), that indicates that the problem occurs when mapply.py inspects my method. 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) As far as I can tell, this means that co_argcount is 1, which makes 'names' == [self,]. Passing in positional arguments to the method then fails as len(positional) > len(names). (All this is taken from around line 54 of mapply.py) Well, that seems to be why my code fails. Can anyone tell me either what I'm doing wrong or tell me I've found a bug. The latter seems pretty unlikely I would think - I'm assuming this code has been around and working for quite a while now. cheers, tim 'File "D:\\Zlave\\zope251\\lib\\python\\ZPublisher\\Publish.py", line 150, in publish_module\n response = publish(request, module_name, after_list, debug=debug)', 'File "D:\\Zlave\\zope251\\lib\\python\\Products\\Localizer\\__init__.py", line 65, in new_publish\n mapply)', 'File "D:\\Zlave\\zope251\\lib\\python\\ZPublisher\\Publish.py", line 114, in publish\n sys.exc_info()[2],', 'File "D:\\Zlave\\zope251\\lib\\python\\Zope\\__init__.py", line 159, in zpublisher_exception_hook\n f(client, REQUEST, t, v, traceback)', 'File "D:\\Zlave\\zope251\\lib\\python\\ZPublisher\\Publish.py", line 98, in publish\n request, bind=1)', 'File "D:\\Zlave\\zope251\\lib\\python\\ZPublisher\\mapply.py", line 69, in mapply\n if len(positional) > nargs: raise TypeError, \'too many arguments\' * One final unrelated point. I was only able to get this far by hacking at ZPublisher/xmlrpc.py so that def exception(self...) appended the 'server-side' traceback to the faultString that is returned to the client. This seems like a *very* useful feature. Any chance of this getting implemented?
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. 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? It may be that there's a way to achieve what you want, while still keeping things reasonably explicit. -- Steve Alexander
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
Tim Hicks wrote:
Given a call signature like:
def method(self, *args, **kw)
In this way, mapply.py seems to ignore the fact that I want my method to accept an arbitrary number of arguments (line 69).
When mapply was written, its only purpose was to map explicit method parameters to request variables. There was no concept of RPC of any kind, so neither '*args' nor '**kwargs' had any kind of sensible interpretation. So, yes, mapply does ignore what you want :-) Unfortunately, given the way that XML-RPC and WebDAV have been piled on top of the initial implementation, I'm not sure how this could be fixed properly in Zope 2.x. Sorry, Evan @ 4-am
Evan Simpson said:
Tim Hicks wrote:
Given a call signature like:
def method(self, *args, **kw)
In this way, mapply.py seems to ignore the fact that I want my method to accept an arbitrary number of arguments (line 69).
When mapply was written, its only purpose was to map explicit method parameters to request variables. There was no concept of RPC of any kind, so neither '*args' nor '**kwargs' had any kind of sensible interpretation.
So, yes, mapply does ignore what you want :-)
Unfortunately, given the way that XML-RPC and WebDAV have been piled on top of the initial implementation, I'm not sure how this could be fixed properly in Zope 2.x.
Sorry,
Evan @ 4-am
Evan, thanks for at least confirming my fears. I've got a workaround going now; albeit with slightly hobbled functionality. As is the standard cry at these times - 'will this be fixed in Zope3?' cheers, tim
Tim Hicks wrote:
As is the standard cry at these times - 'will this be fixed in Zope3?'
Tch. *Everything* will be fixed in Zope 3, doncha know! Seriously, though, Zope 3 is using a refactored services model with stuff like SOAP and XML_RPC on the designers minds from the start. If it doesn't do what you want, you'll be justified in kicking some people in the shins. Cheers, Evan @ 4-am
participants (3)
-
Evan Simpson -
Steve Alexander -
Tim Hicks