Possible PEP: Improve classmethod/staticmethod syntax

Jeff Epler jepler at unpythonic.net
Wed Jun 4 17:59:50 CEST 2003

On Wed, Jun 04, 2003 at 10:21:07AM -0500, Skip Montanaro wrote:
>     gca> Since decorators are in a dictionary, in what order should they be
>     gca> applied? I though item extraction from a dictionary was, basically,
>     gca> unordered.
> Correct.  The advantage of a dictionary is that the individual elements can
> be more complex.  For the pre- and post-condition stuff this works well.  To
> use lists there you have to extend list constructor syntax somehow, as I
> used in my original message:
>     def foo(...) [pre=foo_pre, post=foo_post]:
>         <normal code here>
> You could also use strings:
>     def foo(...) ['pre=foo_pre', 'post=foo_post']:
>         <normal code here>
> The compiler would presumably split them at the '=' and eval() the right
> hand side where necessary to get at the actual value.

Why not use
    def foo(...) [pre(foo_pre), post(foo_post)]
where pre(x) returns a callable that will add the x precondition to its
argument?  For instance,
    class pre:
        def __init__(self, precondition):
            self.precondition = precondition

        def __call__(self, f):
            return add_precondition(f, self.precondition)

as far as I understand the proposed syntax, the items inside the [...]
are Python expressions (which must evaluate to callable objects), not
just identifiers.

One other message in the thread asked, "what if you want to turn off
pre/postcondition checking" (paraphrase).  I don't see why you wouldn't
be able to change 'pre's behavior before the 'def foo' block, since it's
just any callable.  Something like
    if do_preconditions:
        from preconditions import pre, post
        pre = post = lambda x: x


More information about the Python-list mailing list