Possible PEP: Improve classmethod/staticmethod syntax

Skip Montanaro skip at pobox.com
Wed Jun 4 06:24:11 CEST 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>


    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,


More information about the Python-list mailing list