Possible PEP: Improve classmethod/staticmethod syntax
Skip Montanaro
skip at pobox.com
Wed Jun 4 00:24:11 EDT 2003
bryan> these two "styles" appear to be the same, except the second one
bryan> seems to be more natural and simpler and obvious to me.
Perhaps, but style two limits you to a single "keyword" after the def, and
from a parser standpoint suggests that "staticmethod" should be an actual
keyword. You also have to consider the other modifiers which might
reasonably be applied to a function and how they will be implemented. For
pre- and post-conditions, something like
def foo_pre(...) [contract]:
<design-by-contract code here>
def foo_post(...) [contract]:
<more dbc stuff>
def foo(...) [pre=foo_pre, post=foo_post]:
<normal code here>
or
def foo_pre(...) {'contract': True}:
<design-by-contract code here>
def foo_post(...) {'contract': True}:
<more dbc stuff>
def foo(...) {'pre': foo_pre, 'post': foo_post}:
<normal code here>
might be sufficient to allow foo_pre and foo_post to be compiled in such a
way that when they run they actually see foo's locals as their locals and
allow foo to be compiled in a way that calls the pre-condition function upon
entry and the post-condition function just before return (after the return
value has been computed, but before the return is executed). (FYI, the
above is just right off the top of my sleep-starved brain. I'm sure it's
full of holes.)
Combining that with static methods or class methods and you find the same
mechanism can be easily extended:
def foo(...) {'staticmethod': True, 'pre': foo_pre, 'post': foo_post}:
<normal code here>
so now foo() is a static method with both pre- and post-condition contracts
which are executed at the appropriate times.
and-tim's-your-uncle-ly, yr's,
Skip
More information about the Python-list
mailing list