<DIV>The text says that the third parameter is not required but wouldn't that call for a "z.required = False"?</DIV>
<DIV>&nbsp;</DIV>
<DIV>Also, you mention that "[t]his is the Nevow style of parameter definition."&nbsp; Is there a relationship betweent you (as an individual or as Mr. Zope) to Nevow or do you just like the idea?&nbsp; Nevow is a part of the div-mod package built on twisted right?<BR><BR><B><I>jim &lt;zope3-dev@zope.org&gt;</I></B> wrote:</DIV>
<BLOCKQUOTE class=replbq style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">Status: IsDraftProposal<BR><BR>Author<BR><BR>JimFulton<BR><BR>Problem<BR><BR>Currently, interface method descriptions carry very little useful<BR>information. The only information beyond standard attribute<BR>information is a signature string.<BR><BR>Richer information about methods, especially parameters and return<BR>values would provide a number of benefits:<BR><BR>- Provide more formal, and thus consistent, mehod documentation<BR><BR>- Make it easier to implement statically-typed RPC mechansisms, such<BR>as WSDL<BR><BR>- Make certain types of introspection, such as:<BR>http://dev.zope.org/Zope3/ContainmentConstraints<BR><BR>Proposal<BR><BR>Extend standard method meta data to include parameters and return<BR>values. (Note that, to reduce the scope of this proposal,<BR>preconditions and postconditions are excluded. It would, of course,<BR>be interesting to model these in the
 future.)<BR><BR>This proposal builds on SpecificationUnification.<BR><BR>Methods will grow the following attributes:<BR><BR>- 'parameters', a tuple of parameter specifications<BR><BR>- 'returns', a return-value specification<BR><BR>When a python function is adapted to a method specification, the<BR>function will be called, passing parameter objects. The function can<BR>set attributes on the paramter objects to refine parameter<BR>specifications.<BR><BR>Let's look at an example:<BR><BR>def foo(x, y, z=None):<BR>x.type = zope.schema.Int(min=1, max=10)<BR>y.type = IFoo<BR>y.keyword = True<BR>z.type = float<BR>z.keyword = True<BR>return IBar<BR><BR>In this example, the function 'foo' takes 3 parameters. The first<BR>is requied, must be provided positionally, and must be an<BR>integer between 1 and 10. The second parameter is required, may be<BR>provided positionally or as a keyword argument, and must be an<BR>'IFoo'. The third argument is not required, may be provided<BR>positionally or
 as a keyword, can be either a float or 'None', and<BR>defaults to 'None'. The function returns an 'IBar'.<BR><BR>Functions can have default parameter values that are 'Parameter'<BR>objects. In this case, the default values do not indicate that the<BR>parameter is optional, but simply provide initial parameter<BR>specifications. The function definition::<BR><BR>def foo(x=Parameter(type=zope.schema.Int(min=1, max=10)), <BR>y=Parameter(type=IFoo, keyword=True), <BR>z=Parameter(type=float, keyword=True, default=None),<BR>):<BR>return IBar<BR><BR>Is equivalent to the one above. One could, perhaps, provide<BR>convenience functions that allowed an equivalent definition, like::<BR><BR>from myparameters import Int, Float, Foo, Bar<BR><BR>def foo(x=Int(min=1, max=10), y=Foo(keyword=True), <BR>z=Float(keyword=True, default=None),<BR>):<BR>return Bar()<BR><BR>(This is the Nevow style of parameter definition.)<BR><BR>Parameter objects will have a number of attributes, which can be set<BR>via
 keyword arguments to the constructor, including:<BR><BR>- 'type'<BR><BR>The value specification. If not 'None', this will be adapted to<BR>'IInterface'. A value of 'None' means unknown.<BR><BR>- 'keyword'<BR><BR>A flag indicating whether the parameter may be given as a 'keyword'<BR>parameter. If 'True', then the parameter name is significant. The<BR>default is 'False'. If any parameters have a 'True' 'keyword'<BR>attribute, then all parameters after that parameter in the<BR>'parameters' tuple must have 'True' keyword attributes.<BR><BR>- 'positional'<BR><BR>A flag indicating whether the parameter may be given positionally.<BR>If 'True', then the parameter order in the signature is<BR>significant. The default is 'True'. If any parameters have a 'True'<BR>'positional' attribute, then all parameters before that parameter in<BR>the 'parameters' tuple must have 'True' positional attributes.<BR><BR>- 'variable'<BR><BR>A flag indicating whether the parameter represents
 variable<BR>arguments. A 'parameters' tuple may have at most two variable<BR>parameters. Variable parameters must come after non-variable<BR>parameters. Variable parameters may be keyword or non-keyword<BR>variable parameters, depending on the setting of the keyword<BR>paramter attribute. At most one variable parameter can be either<BR>keyword or non-keyword. For example, they function:<BR><BR>def foo(*args, **kw):<BR>"Does something ..."<BR><BR>Can be modelled as<BR><BR>def foo(args=Paramater(variable=True), <BR>kw=Parameter(varable=True, keyword=True),<BR>):<BR>"Does something ..."<BR><BR>args.description = "...."<BR><BR>The advantage of the second form is that the body of the function<BR>has access to Parameter objects for args and kw, rather than an<BR>empty tuple and an empty dictionary.<BR><BR>- 'description'<BR><BR>A textual description of the attribute<BR><BR>- 'default'<BR><BR>A default value for the parameter. This value is unused if<BR>the 'required' attribute is 'True',
 however, giving a 'default'<BR>argument to the parameter constructor or giving a non- 'Parameter'<BR>default value for a function parameter implies that the parameter<BR>is not required. <BR><BR>- required<BR><BR>A flag indicating whether the parameter is required. This defaults<BR>to 'True'.<BR><BR>--<BR>forwarded from http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/MethodSpecification<BR></BLOCKQUOTE>