Re: [Zope] External method default arg weirdness
Paul Winkler writes:
This is with Zope 2.2.2. If I give a default argument to the external method, and call it from a dtml method, the default gets used even if I pass the argument.
Example: Try creating two external methods and calling them like this from standard_html_footer.
<dtml-var "my_ext_method1(_['id'])"> <dtml-var "my_ext_method2(_['id'])">
Here are the two external method definitions:
def my_ext_method1(id): return "<br>%s" % id
def my_ext_method2(id="oops"): return "<br>%s" % id
Anybody else get this? Why does it do that? I know this only, if the first parameter is called "self".
We use default parameters regularly (in Zope 2.1.6) and they work as expected. Dieter
Dieter Maurer wrote:
Paul Winkler writes:
This is with Zope 2.2.2. If I give a default argument to the external method, and call it from a dtml method, the default gets used even if I pass the argument.
Example: Try creating two external methods and calling them like this from standard_html_footer.
<dtml-var "my_ext_method1(_['id'])"> <dtml-var "my_ext_method2(_['id'])">
Here are the two external method definitions:
def my_ext_method1(id): return "<br>%s" % id
def my_ext_method2(id="oops"): return "<br>%s" % id
Anybody else get this? Why does it do that? I know this only, if the first parameter is called "self".
We use default parameters regularly (in Zope 2.1.6) and they work as expected.
Uhhh... duh, you're right. The methods I was actually using have "self" as first parameter. But I don't understand why that affects the rest of the parameters??? Very un-pythonic. -- ................... paul winkler .................... custom calendars & printing: http://www.calendargalaxy.com A member of ARMS: http://www.reacharms.com home page: http://www.slinkp.com
Paul Winkler writes:
Uhhh... duh, you're right. The methods I was actually using have "self" as first parameter.
But I don't understand why that affects the rest of the parameters??? Very un-pythonic. I agree. The more modern Python scripts solve the same problem much better.
The motivation for this "feature": Often External Methods should behave like methods. Sometimes, they should not. The implementers used the following heuristics to distinguish between these two cases: First, it is tried to call the method with the parameters provided. If this raises a "TypeError" and the first parameter is called "self", then the call is retried, this time with "aq_parent" as first parameter. This magic works only, if the method is called with precisely one parameter less then the required arguments. It breaks very likely, when there are default parameters. In this case, you need to pass the "self" parameter explicitly and can not count on the magic. Dieter
Dieter Maurer wrote:
Paul Winkler writes:
But I don't understand why that affects the rest of the parameters??? Very un-pythonic.
I agree. The more modern Python scripts solve the same problem much better.
The motivation for this "feature":
Often External Methods should behave like methods. Sometimes, they should not.
The implementers used the following heuristics to distinguish between these two cases:
First, it is tried to call the method with the parameters provided. If this raises a "TypeError" and the first parameter is called "self", then the call is retried, this time with "aq_parent" as first parameter.
This magic works only, if the method is called with precisely one parameter less then the required arguments. It breaks very likely, when there are default parameters. In this case, you need to pass the "self" parameter explicitly and can not count on the magic.
Thanks for the clarification. Now I see why it's done that way, but I still think it's a pretty dodgy solution - it's like, "Here you can write python code that will behave like you expect it to, but it will fail under certain obscure circumstances, and when it breaks the traceback error will not help you." Too much magic hand-waving for me. I'll try python scripts, see if that's better. -- ................... paul winkler .................... custom calendars & printing: http://www.calendargalaxy.com A member of ARMS: http://www.reacharms.com home page: http://www.slinkp.com
* Dieter Maurer <dieter@handshake.de> [2001-05-09 22:02]:
This magic works only, if the method is called with precisely one parameter less then the required arguments. It breaks very likely, when there are default parameters. In this case, you need to pass the "self" parameter explicitly and can not count on the magic.
Nice. So http://www.zope.org/Documentation/How-To/ExternalMethods is wrong in claiming that --cut-- Argument semantics for External Methods are identical to those for normal Python methods. You can define External Methods with default or keyword arguments just as you can in Python. --cut-- *sigh* Is there any decent, up-to-date information about these hidden gotchas in Zope? Cheers, Nils
participants (3)
-
Dieter Maurer -
Nils Kassube -
Paul Winkler