Possible PEP: Improve classmethod/staticmethod syntax

Bryan belred1 at yahoo.com
Wed Jun 4 07:55:36 CEST 2003


"Skip Montanaro" <skip at pobox.com> wrote in message
news:mailman.1054700708.6942.python-list at python.org...
>
>     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
>


thanks skip... now i can see the elegance of this solution.  wouldn't this
also solve the pre/post conditions that are currently put in comments with
another current solution?  but, how would you handle pre/post conditions
that are only supposed to be used in a debug version?

bryan






More information about the Python-list mailing list