[Magnus Lie Hetland]
>I was just browsing the documentation at jython.org, and I read about the
>convention with @sig in the docstring of functions.
>
>Since Python now (by version 2.1a) supports function attributes [1], I
>assume this will be included in future (2.1?) versions of Jython.
Yes, it will be part of jython 2.1.
>In that case, wouldn't
>that be nice to have a .sig attribute (or even .signature, which gets my
>vote,
>or .__signature__ or something) instead of (or -- for backwards
>compatibility
>-- in addition to) the docstring convention (or, as some might call it,
>"hack" ;-)?
It would be nice, but I'm not entirely sure it is possible. The function
attributes are a runtime feature, the @sig is very much a compile time
feature.
We could add some addition requirement to the use of function
attributes, like:
- They must be specified as part of the class def
- They must use the attribute syntax
With something like this, it might be possible to detect function
attribute syntacticly, but that would cause these two valid uses of
function attribute to be ignored:
class Foo:
def bar(self):
pass
bar.__dict__['sig'] = "public void bar()"
Foo.bar.sig = "public void bar()"
>At least it seems this is the sort of thing function attributes was made
>for...
I'm guessing it was made to improve the runtime introspection of
functions. Public/private methods in Zope springs to mind. The examples
listed in the pep are also about runtime inspection. Adding static type
info isn't used as an example in the pep.
>Example of use:
>
>def setExpression(self, e):
> # Do something...
> pass
>setExpression.signature = "public void setExpression(java.lang.String e)"
>
>(I'm sure it might be seen as a drawback that the signature must be set
>outside
>the function. I don't really feel it matters much...)
It may also be assigned from outside the module. That would matter a
little bit from the compiler's POV <wink>.
regards,
finn
|
