Possible PEP: Improve classmethod/staticmethod syntax
Bryan
belred1 at yahoo.com
Wed Jun 4 01:55:36 EDT 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